From trac at galois.com  Fri Jan  1 02:25:40 2010
From: trac at galois.com (GHC)
Date: Fri Jan  1 01:58:57 2010
Subject: [GHC] #3798: Problem with wxHaskell
Message-ID: <047.492dda442ff44524f4a71fea7b399885@localhost>

#3798: Problem with wxHaskell
---------------------------------+------------------------------------------
    Reporter:  MNorrish          |       Owner:          
        Type:  bug               |      Status:  new     
    Priority:  normal            |   Component:  Compiler
     Version:  6.10.4            |    Keywords:          
          Os:  Linux             |    Testcase:          
Architecture:  Unknown/Multiple  |     Failure:  Other   
---------------------------------+------------------------------------------
 Hello.hs is a GUI hello world program I copied and pasted off
 http://en.wikibooks.org/wiki/Haskell/GUI. I have wxHaskell and ghc, and my
 attempt to compile it gives

 mark@mark-laptop:~/MyCode$ ghc -package wx Hello.hs -o bin
 Binary: Int64 truncated to fit in 32 bit Int
 ghc: panic! (the 'impossible' happened)
   (GHC version 6.10.4 for i386-unknown-linux):
         Prelude.chr: bad argument

 Meanwhile, running it off ghci gives a series of successfully linked and
 loaded packages, terminating with

 Loading package wxdirect-0.12.1.1 ... linking ... done.
 Loading package wxcore-0.12.1.2 ... <command line>: can't load .so/.DLL
 for: stdc++ (libstdc++.so: cannot open shared object file: No such file or
 directory)

 (I put type of failure as other because it's a GHC panic and a GHCi
 failure and probably some other sort of bug too.)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3798>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  1 12:15:22 2010
From: trac at galois.com (GHC)
Date: Fri Jan  1 11:48:33 2010
Subject: [GHC] #3799: undefined symbols and undefined references possibly
 related to template haskell
Message-ID: <049.4a0311c347285cc6754ed4f6a532bc0a@localhost>

#3799: undefined symbols and undefined references possibly related to template
haskell
---------------------------------+------------------------------------------
    Reporter:  JeremyShaw        |       Owner:                                               
        Type:  bug               |      Status:  new                                          
    Priority:  normal            |   Component:  Compiler                                     
     Version:  6.12.1            |    Keywords:  undefined symbols references template haskell
          Os:  Unknown/Multiple  |    Testcase:                                               
Architecture:  Unknown/Multiple  |     Failure:  Compile-time crash                           
---------------------------------+------------------------------------------
 I have seen a number of instances where template-haskell (?) fails at
 compile time due to missing symbols. For example, when building happstack-
 data:

 {{{
 > [ 7 of 16] Compiling Happstack.Data.Xml.Base (
 > src/Happstack/Data/Xml/Base.hs, dist/build/Happstack/Data/Xml/Base.o )
 > Loading package ghc-prim ... linking ... done.
 > Loading package integer-gmp ... linking ... done.
 > Loading package base ... linking ... done.
 > Loading package array-0.3.0.0 ... linking ... done.
 > Loading package bytestring-0.9.1.5 ... linking ... done.
 > Loading package containers-0.3.0.0 ... linking ... done.
 > Loading package pretty-1.0.1.1 ... linking ... done.
 > Loading package template-haskell ... linking ... done.
 > Loading package syb-with-class-0.6.1 ... linking ... done.
 > Loading package HUnit-1.2.2.1 ... linking ... done.
 > Loading package syb-0.1.0.2 ... linking ... done.
 > Loading package base-3.0.3.2 ... linking ... done.
 > Loading package old-locale-1.0.0.2 ... linking ... done.
 > Loading package time-1.1.4 ... linking ... done.
 > Loading package random-1.0.0.2 ... linking ... done.
 > Loading package QuickCheck-1.2.0.0 ... linking ... done.
 > Loading package extensible-exceptions-0.1.1.1 ... linking ... done.
 > Loading package mtl-1.1.0.2 ... linking ... done.
 > Loading package old-time-1.0.0.3 ... linking ... done.
 > Loading package parsec-2.1.0.1 ... linking ... done.
 > Loading package hsemail-1.3 ... linking ... done.
 > Loading package network-2.2.1.5 ... linking ... done.
 > Loading package SMTPClient-1.0.1 ... linking ... done.
 > Loading package filepath-1.1.0.3 ... linking ... done.
 > Loading package unix-2.4.0.0 ... linking ... done.
 > Loading package directory-1.0.1.0 ... linking ... done.
 > Loading package process-1.0.1.2 ... linking ... done.
 > Loading package hslogger-1.0.7 ... linking ... done.
 > Loading package deepseq-1.1.0.0 ... linking ... done.
 > Loading package parallel-2.2.0.1 ... linking ... done.
 > Loading package strict-concurrency-0.2.2 ... linking ... done.
 > Loading package unix-compat-0.1.2.1 ... linking ... done.
 > Loading package happstack-util-0.4.1 ... linking ... done.
 > Loading package binary-0.5.0.2 ... linking ... done.
 > Loading package haskell98 ... linking ... done.
 > Loading package HaXml-1.13.3 ... linking ... done.
 > Loading package ffi-1.0 ... linking ... done.
 > ghc:
 > unknown symbol
 >
 `_sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataT
 ypeZMad6eZN_closure'
 > <<<<<
 }}}

 or in some private code:

 {{{
 Loading package extensible-exceptions-0.1.1.1 ... linking ... done.
 ghc: /usr/lib/haskell-packages/ghc6/lib/generic-formlets-1.53/ghc-6.12.1
 /HSgeneric-formlets-1.53.o: unknown symbol
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad9AZN_closure'
 Loading package hsemail-1.3 ... linking ... done.
 }}}

 The work around so far has been to compile with {{{-O0}}}. However, it is
 not consistent *what* needs to be compiled with -O0. In the case of
 happstack-data, compiling happstack-data with {{{-O0}}} fixed the problem.
 In the second example I pasted, I actually had to recompile the library
 that the missing symbol was coming from with {{{-O0}}}.

 I have also seen similar linking errors during the final link of an
 executable:

 {{{
 Linking dist/build/senioritymatters/senioritymatters ...
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Server.o: In
 function `s5OwR_info':
 (.text+0x10559): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Server.o: In
 function `r5Hbl_info':
 (.text+0x105a1): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Server.o: In
 function `r5Hbj_srt':
 (.data+0x2cec): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Server.o: In
 function `r5Hbl_srt':
 (.data+0x2cf8): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Store.o: In
 function `s5uFy_info':
 (.text+0x7ad5): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Store.o: In
 function `s5uFy_info':
 (.text+0x7b1d): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Store.o: In
 function `r5rnO_closure':
 (.data+0x16b0): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Store.o: In
 function `r5rnO_closure':
 (.data+0x16bc): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o:
 In function `s48Uv_info':
 (.text+0x6151d): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o:
 In function `s48Uv_info':
 (.text+0x61565): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o:
 In function `s4962_info':
 (.text+0x61d69): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o:
 In function `s4962_info':
 (.text+0x61db1): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o:
 In function `s4jTk_info':
 (.text+0x860c1): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o:
 In function `s4jTk_info':
 (.text+0x86109): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o:
 In function `s3xkI_closure':
 (.data+0x74c8): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o:
 In function `s3xkI_closure':
 (.data+0x74d4): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o:
 In function `s3xkI_closure':
 (.data+0x76a8): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o:
 In function `s3xkI_closure':
 (.data+0x76b4): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o:
 In function `r3or3_closure':
 (.data+0xb824): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
 dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o:
 In function `r3or3_closure':
 (.data+0xb830): undefined reference to
 `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
 collect2: ld returned 1 exit status
 done.
 Loading package QuickCheck-2.1.0.2 ... linking ... done.
 Loading package ffi-1.0 ... linking ... done.
 }}}

 In this case, compiling with {{{-O0}}} also fixed the linking errors.
 However, I was also able to compile with {{{-O2 -fignore-interface-
 pragmas}}}. In the case of the template-haskell errors, {{{-fignore-
 interface-pragmas}}} did not help.


 It seems that some GHC 6.12.1 users are able to compile happstack-data
 with out any problems. We have seen it happen under Linux and Mac OS X,
 and 32bit and 64bit. So there is no clear pattern there yet.

 The one pattern I have noticed is that the undefined symbols/references
 always seem to end with {{{_closure}}}.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  1 13:16:42 2010
From: trac at galois.com (GHC)
Date: Fri Jan  1 12:49:52 2010
Subject: [GHC] #3800: sizeofByteArray# returns allocated words,
 not requested length in bytes
Message-ID: <052.ddae457e72f5875b2acee6868c0b8060@localhost>

#3800: sizeofByteArray# returns allocated words, not requested length in bytes
---------------------------------+------------------------------------------
    Reporter:  AntoineLatter     |       Owner:  AntoineLatter              
        Type:  bug               |      Status:  new                        
    Priority:  normal            |   Component:  Compiler                   
     Version:  6.12.1            |    Keywords:                             
          Os:  Unknown/Multiple  |    Testcase:                             
Architecture:  Unknown/Multiple  |     Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------
 A byte array allocated with (GHC.Prim.newByteArray# 7) will report it's
 size as '8' - that is, the stored size in StgArrWords is the number of
 allocated words, not the number of requested bytes.

 This menas that if I want to a GHC.Prim.ByteArray# or MutableByteArray# as
 an array type, I need a separate length fields.

 See also: http://www.haskell.org/pipermail/glasgow-haskell-
 users/2009-December/018199.html

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3800>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  1 14:36:12 2010
From: trac at galois.com (GHC)
Date: Fri Jan  1 14:09:23 2010
Subject: [GHC] #3799: undefined symbols and undefined references
 possibly related to template haskell
In-Reply-To: <049.4a0311c347285cc6754ed4f6a532bc0a@localhost>
References: <049.4a0311c347285cc6754ed4f6a532bc0a@localhost>
Message-ID: <058.16dde695d1cf7e9c3c955fd6889eb7e9@localhost>

#3799: undefined symbols and undefined references possibly related to template
haskell
---------------------------------+------------------------------------------
  Reporter:  JeremyShaw          |          Owner:                                               
      Type:  bug                 |         Status:  new                                          
  Priority:  normal              |      Milestone:                                               
 Component:  Compiler            |        Version:  6.12.1                                       
Resolution:                      |       Keywords:  undefined symbols references template haskell
Difficulty:                      |             Os:  Unknown/Multiple                             
  Testcase:                      |   Architecture:  Unknown/Multiple                             
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Changes (by simonmar):

  * difficulty:  =>

Comment:

 does it happen with a clean compile, or is it when recompiling? (I'm
 wondering about #481)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  1 14:47:35 2010
From: trac at galois.com (GHC)
Date: Fri Jan  1 14:20:46 2010
Subject: [GHC] #3800: sizeofByteArray# returns allocated words,
 not requested length in bytes
In-Reply-To: <052.ddae457e72f5875b2acee6868c0b8060@localhost>
References: <052.ddae457e72f5875b2acee6868c0b8060@localhost>
Message-ID: <061.a25ab111f726815dfc6cb6d14a70e06b@localhost>

#3800: sizeofByteArray# returns allocated words, not requested length in bytes
------------------------------------------+---------------------------------
  Reporter:  AntoineLatter                |          Owner:  simonmar        
      Type:  bug                          |         Status:  new             
  Priority:  high                         |      Milestone:  6.14.1          
 Component:  Compiler                     |        Version:  6.12.1          
Resolution:                               |       Keywords:                  
Difficulty:                               |             Os:  Unknown/Multiple
  Testcase:                               |   Architecture:  Unknown/Multiple
   Failure:  Incorrect result at runtime  |  
------------------------------------------+---------------------------------
Changes (by simonmar):

  * priority:  normal => high
  * difficulty:  =>
  * owner:  AntoineLatter => simonmar
  * milestone:  => 6.14.1

Comment:

 Nice patch, looks perfect.  I'll milestone this for 6.14.1, since it would
 be a change in behaviour that people will want to rely on, so we can't
 make that change in a minor release.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3800#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  1 15:06:37 2010
From: trac at galois.com (GHC)
Date: Fri Jan  1 14:39:47 2010
Subject: [GHC] #3787: GHC 6.12.1 panic
In-Reply-To: <047.0ece8a101cc798eefac149b629f279fa@localhost>
References: <047.0ece8a101cc798eefac149b629f279fa@localhost>
Message-ID: <056.cb57de66c4b0ad87f0d57088d2a73bda@localhost>

#3787: GHC 6.12.1 panic
---------------------------------+------------------------------------------
  Reporter:  blamario            |          Owner:  simonmar      
      Type:  bug                 |         Status:  new           
  Priority:  high                |      Milestone:  6.12.2        
 Component:  Compiler            |        Version:  6.12.1        
Resolution:                      |       Keywords:  panic         
Difficulty:                      |             Os:  Linux         
  Testcase:                      |   Architecture:  x86_64 (amd64)
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Comment (by blamario):

 It might be worth a mention that GHC 6.10.4 gives exactly the same
 results.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3787#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  1 15:24:33 2010
From: trac at galois.com (GHC)
Date: Fri Jan  1 14:57:44 2010
Subject: [GHC] #3799: undefined symbols and undefined references
 possibly related to template haskell
In-Reply-To: <049.4a0311c347285cc6754ed4f6a532bc0a@localhost>
References: <049.4a0311c347285cc6754ed4f6a532bc0a@localhost>
Message-ID: <058.a8e5156800575e3b3bbfdba89afaa3b6@localhost>

#3799: undefined symbols and undefined references possibly related to template
haskell
---------------------------------+------------------------------------------
  Reporter:  JeremyShaw          |          Owner:                                               
      Type:  bug                 |         Status:  new                                          
  Priority:  normal              |      Milestone:                                               
 Component:  Compiler            |        Version:  6.12.1                                       
Resolution:                      |       Keywords:  undefined symbols references template haskell
Difficulty:                      |             Os:  Unknown/Multiple                             
  Testcase:                      |   Architecture:  Unknown/Multiple                             
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Comment (by JeremyShaw):

 Alas, it happens even during a clean build. Happens even if you remove
 everything and start with a vanilla install.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  1 17:18:28 2010
From: trac at galois.com (GHC)
Date: Fri Jan  1 16:51:38 2010
Subject: [GHC] #3751: Panic! the 'impossible' happened: charType: '\167'
In-Reply-To: <053.09139966f34278370b63f1b3d0e8a13b@localhost>
References: <053.09139966f34278370b63f1b3d0e8a13b@localhost>
Message-ID: <062.e5f30bb091d87ac420a4f7ebb99f8321@localhost>

#3751: Panic! the 'impossible' happened: charType: '\167'
---------------------------------+------------------------------------------
  Reporter:  moleculeColony      |          Owner:  igloo           
      Type:  merge               |         Status:  closed          
  Priority:  normal              |      Milestone:  6.12.2          
 Component:  Compiler (Parser)   |        Version:  6.10.4          
Resolution:  fixed               |       Keywords:  lexical error   
Difficulty:                      |             Os:  Unknown/Multiple
  Testcase:                      |   Architecture:  Unknown/Multiple
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3751#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  1 17:18:45 2010
From: trac at galois.com (GHC)
Date: Fri Jan  1 16:51:54 2010
Subject: [GHC] #3776: Warning: The import of `B.foo' from module `A' is
 redundant
In-Reply-To: <045.524d47037f8ce3759915de36370eb1f3@localhost>
References: <045.524d47037f8ce3759915de36370eb1f3@localhost>
Message-ID: <054.a7b6b7b9fdd9f9eef7f1ec0d640568f4@localhost>

#3776: Warning: The import of `B.foo' from module `A' is redundant
---------------------------+------------------------------------------------
  Reporter:  slyfox        |          Owner:  igloo                  
      Type:  merge         |         Status:  closed                 
  Priority:  normal        |      Milestone:  6.12.2                 
 Component:  Compiler      |        Version:  6.12.1                 
Resolution:  fixed         |       Keywords:  import, redundant, Wall
Difficulty:                |             Os:  Unknown/Multiple       
  Testcase:  module/T3776  |   Architecture:  Unknown/Multiple       
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3776#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  1 17:19:00 2010
From: trac at galois.com (GHC)
Date: Fri Jan  1 16:52:10 2010
Subject: [GHC] #3245: Quadratic slowdown in Data.Typeable
In-Reply-To: <044.8f6ad688a6e54aadf1867244399f152a@localhost>
References: <044.8f6ad688a6e54aadf1867244399f152a@localhost>
Message-ID: <053.a57a9ef70b5bc8a3fdb2deccdfdf56f7@localhost>

#3245: Quadratic slowdown in Data.Typeable
--------------------------------------+-------------------------------------
  Reporter:  guest                    |          Owner:  igloo      
      Type:  merge                    |         Status:  closed     
  Priority:  normal                   |      Milestone:  6.12 branch
 Component:  libraries (other)        |        Version:  6.10.1     
Resolution:  fixed                    |       Keywords:             
Difficulty:  Unknown                  |             Os:  Linux      
  Testcase:  perf/should_run/T3245    |   Architecture:  x86        
   Failure:  Runtime performance bug  |  
--------------------------------------+-------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3245#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  1 17:19:09 2010
From: trac at galois.com (GHC)
Date: Fri Jan  1 16:52:20 2010
Subject: [GHC] #3728: configure should omit full path in unistd.h,
 stdlib.h return type tests
In-Reply-To: <043.d33bce572e64777410efea0050887938@localhost>
References: <043.d33bce572e64777410efea0050887938@localhost>
Message-ID: <052.ae8962821977ade126e48b6db471cdf2@localhost>

#3728: configure should omit full path in unistd.h, stdlib.h return type tests
----------------------------------+-----------------------------------------
  Reporter:  donn                 |          Owner:  igloo     
      Type:  merge                |         Status:  closed    
  Priority:  normal               |      Milestone:  6.12.2    
 Component:  Compiler             |        Version:  6.12.1 RC1
Resolution:  fixed                |       Keywords:            
Difficulty:                       |             Os:  Other     
  Testcase:                       |   Architecture:  x86       
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3728#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  2 02:41:51 2010
From: trac at galois.com (GHC)
Date: Sat Jan  2 02:15:01 2010
Subject: [GHC] #3800: sizeofByteArray# returns allocated words,
 not requested length in bytes
In-Reply-To: <052.ddae457e72f5875b2acee6868c0b8060@localhost>
References: <052.ddae457e72f5875b2acee6868c0b8060@localhost>
Message-ID: <061.8ce70263a50b8a82e87f3c288eb4db29@localhost>

#3800: sizeofByteArray# returns allocated words, not requested length in bytes
------------------------------------------+---------------------------------
  Reporter:  AntoineLatter                |          Owner:  simonmar        
      Type:  bug                          |         Status:  new             
  Priority:  high                         |      Milestone:  6.14.1          
 Component:  Compiler                     |        Version:  6.12.1          
Resolution:                               |       Keywords:                  
Difficulty:                               |             Os:  Unknown/Multiple
  Testcase:                               |   Architecture:  Unknown/Multiple
   Failure:  Incorrect result at runtime  |  
------------------------------------------+---------------------------------
Changes (by AntoineLatter):

 * cc: aslatter@gmail.com (added)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3800#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  2 15:09:18 2010
From: trac at galois.com (GHC)
Date: Sat Jan  2 14:42:31 2010
Subject: [GHC] #589: Various poor type error messages
In-Reply-To: <071.0082e1e4c49b5d4a87885a3c5b2e9b4f@localhost>
References: <071.0082e1e4c49b5d4a87885a3c5b2e9b4f@localhost>
Message-ID: <080.7b38bf0b4200fd9fe03b1c486afc2ddb@localhost>

#589: Various poor type error messages
-----------------------------------------------+----------------------------
  Reporter:  Peter A Jonsson [pj@ludd.ltu.se]  |          Owner:                  
      Type:  bug                               |         Status:  new             
  Priority:  low                               |      Milestone:  _|_             
 Component:  Compiler (Type checker)           |        Version:  6.4.1           
Resolution:                                    |       Keywords:                  
Difficulty:  Unknown                           |             Os:  Unknown/Multiple
  Testcase:                                    |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown                      |  
-----------------------------------------------+----------------------------
Changes (by igloo):

  * failure:  => None/Unknown

Old description:

> {{{
> Hello,
>
> I read the summary of the survey and noticed you wanted feedback on
> where error messages could be improved. I looked up some (simple)
> examples of type errors and ran them through ghc. I do not make any
> claims to be an HCI expert, just a mere mortal with an opinion.
>
> Code:
>
> 1 module Test2 where
> 2
> 3 fib n = if (3 > n) then 1 else (fib (n - 1) + fib (n - 2))
> 4 k = fib 's'
>
> Error message:
>
> Test2.hs:4:
>     No instance for (Num Char)
>       arising from use of `fib' at Test2.hs:4
>     In the definition of `k': k = fib 's'
>
> This isn't a bad error message in my humble opinion, it does pinpoint
> that I'm doing something wrong in line 4, and that there isn't an
> instance for Num Char doesn't come as a surprise. However I think it
> could have been more helpful by telling me that I tried to pass a Char
> to a function which expected an (Ord a, Num a) => a as its parameter.
>
> Code:
>
> 1 module Test4 where
> 2
> 3 k :: Int -> Int
> 4 k l = 2.0*l
>
> Error message:
>
> Test4.hs:4:
>     No instance for (Fractional Int)
>       arising from the literal `2.0' at Test4.hs:4
>     In the first argument of `(*)', namely `2.0'
>     In the definition of `k': k l = 2.0 * l
>
> One reason this kind of error could happen is an inexperienced user
> declaring the wrong type for his function, or not knowing that 2.0
> would be interpreted as a Fractional.
>
> Code:
>
> 1 module Test7 where
> 2
> 3 len' xs = head (xs) + (length xs)
> 4 o = len' "GH"
>
> Error message:
>
> Test7.hs:4:
>     Couldn't match `Int' against `Char'
>         Expected type: [Int]
>         Inferred type: [Char]
>     In the first argument of `len'', namely `"GH"'
>     In the definition of `o': o = len' "GH"
>
> I ran this through Hugs version November 2002 and got this error
> message:
>
> ERROR "Test7.hs":4 - Type error in application
> *** Expression     : len' "GH"
> *** Term           : "GH"
> *** Type           : String
> *** Does not match : [Int]
>
> I find the Hugs message more clear, but that might be my background.
>
> Code:
>
> 1 module Test8 where
> 2
> 3 f = head 3
>
> Error message:
>
> Test8.hs:3:
>     No instance for (Num [a])
>       arising from the literal `3' at Test8.hs:3
>     Possible cause: the monomorphism restriction applied to the
> following:
>       f :: a (bound at Test8.hs:3)
>     Probable fix: give these definition(s) an explicit type signature
>     In the first argument of `head', namely `3'
>     In the definition of `f': f = head 3
>
> This one I find outright scary. For "wrong = div 3 8 + 1/2" it gives
> an error message that somewhat helps me guess the error, but the above
> doesn't even come close to helping me.
>
> / Peter
> }}}

New description:

 Hello,

 I read the summary of the survey and noticed you wanted feedback on
 where error messages could be improved. I looked up some (simple)
 examples of type errors and ran them through ghc. I do not make any
 claims to be an HCI expert, just a mere mortal with an opinion.

 '''Type error 1'''

 Code:
 {{{
 1 module Test2 where
 2
 3 fib n = if (3 > n) then 1 else (fib (n - 1) + fib (n - 2))
 4 k = fib 's'
 }}}
 Error message:
 {{{
 Test2.hs:4:
     No instance for (Num Char)
       arising from use of `fib' at Test2.hs:4
     In the definition of `k': k = fib 's'
 }}}

 This isn't a bad error message in my humble opinion, it does pinpoint
 that I'm doing something wrong in line 4, and that there isn't an
 instance for Num Char doesn't come as a surprise. However I think it
 could have been more helpful by telling me that I tried to pass a Char
 to a function which expected an (Ord a, Num a) => a as its parameter.

 '''Type error 2'''

 Code:
 {{{
 1 module Test4 where
 2
 3 k :: Int -> Int
 4 k l = 2.0*l
 }}}
 Error message:
 {{{
 Test4.hs:4:
     No instance for (Fractional Int)
       arising from the literal `2.0' at Test4.hs:4
     In the first argument of `(*)', namely `2.0'
     In the definition of `k': k l = 2.0 * l
 }}}
 One reason this kind of error could happen is an inexperienced user
 declaring the wrong type for his function, or not knowing that 2.0
 would be interpreted as a Fractional.

 '''Type error 3'''

 Code:
 {{{
 1 module Test7 where
 2
 3 len' xs = head (xs) + (length xs)
 4 o = len' "GH"
 }}}
 Error message:
 {{{
 Test7.hs:4:
     Couldn't match `Int' against `Char'
         Expected type: [Int]
         Inferred type: [Char]
     In the first argument of `len'', namely `"GH"'
     In the definition of `o': o = len' "GH"
 }}}
 I ran this through Hugs version November 2002 and got this error
 message:
 {{{
 ERROR "Test7.hs":4 - Type error in application
 *** Expression     : len' "GH"
 *** Term           : "GH"
 *** Type           : String
 *** Does not match : [Int]
 }}}
 I find the Hugs message more clear, but that might be my background.

 '''Type error 4'''

 Code:
 {{{
 1 module Test8 where
 2
 3 f = head 3
 }}}
 Error message:
 {{{
 Test8.hs:3:
     No instance for (Num [a])
       arising from the literal `3' at Test8.hs:3
     Possible cause: the monomorphism restriction applied to the following:
       f :: a (bound at Test8.hs:3)
     Probable fix: give these definition(s) an explicit type signature
     In the first argument of `head', namely `3'
     In the definition of `f': f = head 3
 }}}
 This one I find outright scary. For "wrong = div 3 8 + 1/2" it gives
 an error message that somewhat helps me guess the error, but the above
 doesn't even come close to helping me.

 / Peter

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/589#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  2 15:23:56 2010
From: trac at galois.com (GHC)
Date: Sat Jan  2 14:57:08 2010
Subject: [GHC] #589: Various poor type error messages
In-Reply-To: <071.0082e1e4c49b5d4a87885a3c5b2e9b4f@localhost>
References: <071.0082e1e4c49b5d4a87885a3c5b2e9b4f@localhost>
Message-ID: <080.fa29f2fa9a4e01bc8938b45889b0440b@localhost>

#589: Various poor type error messages
-----------------------------------------------+----------------------------
  Reporter:  Peter A Jonsson [pj@ludd.ltu.se]  |          Owner:                  
      Type:  bug                               |         Status:  new             
  Priority:  low                               |      Milestone:  _|_             
 Component:  Compiler (Type checker)           |        Version:  6.4.1           
Resolution:                                    |       Keywords:                  
Difficulty:  Unknown                           |             Os:  Unknown/Multiple
  Testcase:                                    |   Architecture:  Unknown/Multiple
   Failure:  Other                             |  
-----------------------------------------------+----------------------------
Changes (by igloo):

  * failure:  None/Unknown => Other

Comment:

 The errors are essentially unchanged in 6.12.1.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/589#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  2 16:02:36 2010
From: trac at galois.com (GHC)
Date: Sat Jan  2 15:35:43 2010
Subject: [GHC] #590: hsc2hs: quoting of macro arguments containing commas
In-Reply-To: <080.fa7c1970e00851ba12c0e6456c768a6f@localhost>
References: <080.fa7c1970e00851ba12c0e6456c768a6f@localhost>
Message-ID: <089.449966a0f8f62dd67b0310fcb62884dd@localhost>

#590: hsc2hs: quoting of macro arguments containing commas
--------------------------------------------------------+-------------------
  Reporter:  Dimitry Golubovsky <golubovsky@gmail.com>  |          Owner:  igloo           
      Type:  bug                                        |         Status:  new             
  Priority:  low                                        |      Milestone:  Not GHC         
 Component:  hsc2hs                                     |        Version:  6.4.1           
Resolution:                                             |       Keywords:                  
Difficulty:  Unknown                                    |             Os:  Unknown/Multiple
  Testcase:                                             |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown                               |  
--------------------------------------------------------+-------------------
Changes (by igloo):

  * owner:  => igloo
  * failure:  => None/Unknown

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/590#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  2 16:19:40 2010
From: trac at galois.com (GHC)
Date: Sat Jan  2 15:52:48 2010
Subject: [GHC] #594: Support use of SSE2 in the x86 native code genreator
In-Reply-To: <047.5190f55d4ad1363b95d98c092787782f@localhost>
References: <047.5190f55d4ad1363b95d98c092787782f@localhost>
Message-ID: <056.8f5ac30397fe29fadc0cb4151611fa85@localhost>

#594: Support use of SSE2 in the x86 native code genreator
-----------------------------------------+----------------------------------
  Reporter:  simonmar                    |          Owner:                  
      Type:  task                        |         Status:  new             
  Priority:  normal                      |      Milestone:  6.12 branch     
 Component:  Compiler (NCG)              |        Version:  6.4.1           
Resolution:                              |       Keywords:                  
Difficulty:  Moderate (less than a day)  |             Os:  Unknown/Multiple
  Testcase:  N/A                         |   Architecture:  Unknown/Multiple
   Failure:  Runtime performance bug     |  
-----------------------------------------+----------------------------------
Changes (by igloo):

  * failure:  => Runtime performance bug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/594#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  2 16:27:41 2010
From: trac at galois.com (GHC)
Date: Sat Jan  2 16:00:48 2010
Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern
 checking
In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@localhost>
References: <047.bea78f01cbb904765ad77c751bc8d3af@localhost>
Message-ID: <056.a158f1fcd2d4a37dfe0c1cc0993a1095@localhost>

#595: Overhaul GHC's overlapping/non-exhaustive pattern checking
------------------------------------------------+---------------------------
  Reporter:  simonmar                           |          Owner:                  
      Type:  task                               |         Status:  new             
  Priority:  normal                             |      Milestone:  _|_             
 Component:  Compiler                           |        Version:  None            
Resolution:  None                               |       Keywords:  warnings        
Difficulty:  Difficult (2-5 days)               |             Os:  Unknown/Multiple
  Testcase:  N/A                                |   Architecture:  Unknown/Multiple
   Failure:  Incorrect warning at compile-time  |  
------------------------------------------------+---------------------------
Changes (by igloo):

  * failure:  => Incorrect warning at compile-time

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/595#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  2 16:39:08 2010
From: trac at galois.com (GHC)
Date: Sat Jan  2 16:12:15 2010
Subject: [GHC] #597: Various error messages have inaccurate source
 locations
In-Reply-To: <047.d9b3aa24ce12758448e171cbecc1a26d@localhost>
References: <047.d9b3aa24ce12758448e171cbecc1a26d@localhost>
Message-ID: <056.a0aaecb8181e9dcbc06df7e793d12f0f@localhost>

#597: Various error messages have inaccurate source locations
-----------------------------------------+----------------------------------
  Reporter:  simonmar                    |          Owner:                  
      Type:  task                        |         Status:  new             
  Priority:  low                         |      Milestone:  _|_             
 Component:  Compiler                    |        Version:  None            
Resolution:  None                        |       Keywords:                  
Difficulty:  Moderate (less than a day)  |             Os:  Unknown/Multiple
  Testcase:                              |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown                |  
-----------------------------------------+----------------------------------
Changes (by igloo):

  * failure:  => None/Unknown

Old description:

> Some error messages lack source location information, or have inaccurate
> locations.    Here are the ones we know about:
>
>  * Should point to the import decl:
>    ShowFunctions.hs:1:0
>      Warning: Module `Text.Show.Functions' is imported, but nothing from
> it is used
>
>  * Should point to the instance header:
>    mod41.hs:3:0:
>        Illegal instance declaration for `Eq (Either a a)'
>          (The instance type must be of form (T a b c)
>
>  * Should point to 'deriving *Eq*', not the tycon:
>    tcfail046.hs:9:8:
>      No instance for `Eq (Pid -> Time -> Message a -> (MessList a,
> Continuation a
> ))'
>      When deriving the `Eq' instance for type `Continuation'
>
>  * check_tau_type doesn't have location info?
>    tcfail100.hs:7:0:
>        Type synonym `A' should have 1 argument, but has been given 0
>        In the type synonym declaration for `B'
>
>  * Location in LHsModule from the parser should really span the whole
> file, rather than a point span at (1,0).
>
>  * read016: should be the lhs only?
>  * tcfail044: should be the instance head only.

New description:

 Some error messages lack source location information, or have inaccurate
 locations.    Here are the ones we know about:

  * Should point to the import decl:
 {{{
    ShowFunctions.hs:1:0
      Warning: Module `Text.Show.Functions' is imported, but nothing from
 it is used
 }}}
  * Should point to the instance header:
 {{{
    mod41.hs:3:0:
        Illegal instance declaration for `Eq (Either a a)'
          (The instance type must be of form (T a b c)
 }}}
  * Should point to 'deriving *Eq*', not the tycon:
 {{{
    tcfail046.hs:9:8:
      No instance for `Eq (Pid -> Time -> Message a -> (MessList a,
 Continuation a
 ))'
      When deriving the `Eq' instance for type `Continuation'
 }}}
  * check_tau_type doesn't have location info?
 {{{
    tcfail100.hs:7:0:
        Type synonym `A' should have 1 argument, but has been given 0
        In the type synonym declaration for `B'
 }}}
  * Location in LHsModule from the parser should really span the whole
 file, rather than a point span at (1,0).

  * read016: should be the lhs only?
  * tcfail044: should be the instance head only.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/597#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  2 16:46:01 2010
From: trac at galois.com (GHC)
Date: Sat Jan  2 16:19:11 2010
Subject: [GHC] #605: Optimisation: strict enumerations
In-Reply-To: <047.930f12dd9816334e7bac59b319734f38@localhost>
References: <047.930f12dd9816334e7bac59b319734f38@localhost>
Message-ID: <056.4f176ede80b05568a52eaab5a19204ab@localhost>

#605: Optimisation: strict enumerations
--------------------------------------+-------------------------------------
  Reporter:  simonmar                 |          Owner:                  
      Type:  task                     |         Status:  new             
  Priority:  normal                   |      Milestone:  _|_             
 Component:  Compiler                 |        Version:  None            
Resolution:  None                     |       Keywords:                  
Difficulty:  Difficult (2-5 days)     |             Os:  Unknown/Multiple
  Testcase:  N/A                      |   Architecture:  Unknown/Multiple
   Failure:  Runtime performance bug  |  
--------------------------------------+-------------------------------------
Changes (by igloo):

  * failure:  => Runtime performance bug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/605#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  2 17:03:33 2010
From: trac at galois.com (GHC)
Date: Sat Jan  2 16:36:40 2010
Subject: [GHC] #602: Warning Suppression
In-Reply-To: <047.d851345fc677a304d933040775d25d45@localhost>
References: <047.d851345fc677a304d933040775d25d45@localhost>
Message-ID: <056.c8b7616e4b1ee54002036b694f974d28@localhost>

#602: Warning Suppression
-----------------------------------------+----------------------------------
  Reporter:  simonmar                    |          Owner:                  
      Type:  task                        |         Status:  new             
  Priority:  normal                      |      Milestone:  6.12 branch     
 Component:  Compiler                    |        Version:  None            
Resolution:  None                        |       Keywords:  warnings        
Difficulty:  Moderate (less than a day)  |             Os:  Unknown/Multiple
  Testcase:  N/A                         |   Architecture:  Unknown/Multiple
   Failure:  Other                       |  
-----------------------------------------+----------------------------------
Changes (by igloo):

  * failure:  => Other

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/602#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  3 02:16:06 2010
From: trac at galois.com (GHC)
Date: Sun Jan  3 01:49:13 2010
Subject: [GHC] #3801: ghc-6.10.4: internal error: PAP object entered
Message-ID: <047.7b8b923041b68855da236912614f1972@localhost>

#3801: ghc-6.10.4: internal error: PAP object entered
-------------------------+--------------------------------------------------
    Reporter:  patrikja  |       Owner:               
        Type:  bug       |      Status:  new          
    Priority:  normal    |   Component:  Compiler     
     Version:  6.10.4    |    Keywords:               
          Os:  Linux     |    Testcase:               
Architecture:  x86       |     Failure:  Runtime crash
-------------------------+--------------------------------------------------
 Running the compiled code for a simple program using WX Haskell +
 QuickCheck gives "internal error: PAP object entered". (I cannot submit
 the source code openly right now  because it is a solution to course
 homework in the course I'm teaching Jan-March, but I could send it to
 whoever is assigned to this bug. Just ask patrikja+ghc AT gmail .)

 The error appeared after adding a dependency on QuickCheck (in base) and
 the Control.Monad.Writer (in mtl) - before that it compiled and worked
 fine.

 Searching the trac history most PAP object entered seem to refer to
 http://hackage.haskell.org/trac/ghc/ticket/1372 but I'm not sure how to
 make sure no "mismatched library versions" are around. I'd be happy to
 rebuild / reinstall my whole cabal library setup if there is an easy way
 to do that.

 Another clue may be the libstdc++.so.6 warning I get after each compile -
 see below. (That warning has been there also for all the working versions
 of the code so I'm not sure if it is relevant here.)
 {{{
 patrikj@hel:~/src/gitroot/edu/AFP/Lab1_turtle$ make test
 ghc -package wx --make Lab1_Part2_Task2
 [1 of 3] Compiling Turtle           ( Turtle.lhs, Turtle.o )
 [2 of 3] Compiling Spiral           ( Spiral.lhs, Spiral.o )
 [3 of 3] Compiling Main             ( Lab1_Part2_Task2.lhs,
 Lab1_Part2_Task2.o )
 Linking Lab1_Part2_Task2 ...
 /usr/bin/ld: warning: libstdc++.so.6, needed by
 /usr/lib/libwx_baseu-2.8.so, may conflict with libstdc++.so.7
 ./Lab1_Part2_Task2 0 91
 Lab1_Part2_Task2: internal error: PAP object entered!
     (GHC version 6.10.4 for i386_unknown_linux)
     Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug
 make: *** [test] Avbruten (SIGABRT)

 patrikj@hel:~/src/gitroot/edu/AFP/Lab1_turtle$ uname -a
 Linux hel 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:01:29 UTC 2009
 i686 GNU/Linux
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3801>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  3 02:51:51 2010
From: trac at galois.com (GHC)
Date: Sun Jan  3 02:24:56 2010
Subject: [GHC] #3801: ghc-6.10.4: internal error: PAP object entered
In-Reply-To: <047.7b8b923041b68855da236912614f1972@localhost>
References: <047.7b8b923041b68855da236912614f1972@localhost>
Message-ID: <056.af44fb9441251997fca30511df01b274@localhost>

#3801: ghc-6.10.4: internal error: PAP object entered
-------------------------+--------------------------------------------------
    Reporter:  patrikja  |       Owner:               
        Type:  bug       |      Status:  new          
    Priority:  normal    |   Milestone:               
   Component:  Compiler  |     Version:  6.10.4       
  Resolution:            |    Keywords:               
          Os:  Linux     |    Testcase:               
Architecture:  x86       |     Failure:  Runtime crash
-------------------------+--------------------------------------------------
Comment (by patrikja):

 After testing a bit I can add that just removing the call to quickCheck is
 enough to get the program to work. The version of QuickCheck is as
 follows:
 {{{
 patrikj@hel:~/src/gitroot/edu/AFP/Lab1_turtle$ ghc-pkg list QuickCheck
 /usr/local/lib/ghc-6.10.4/./package.conf:
     QuickCheck-1.2.0.0
 }}}
 It seems unlikely that this is the problem. Also mtl seems to be the
 standard one:
 {{{
 patrikj@hel:~/src/gitroot/edu/AFP/Lab1_turtle$ ghc-pkg list mtl
 /usr/local/lib/ghc-6.10.4/./package.conf:
     mtl-1.1.0.2
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3801#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  3 04:07:53 2010
From: trac at galois.com (GHC)
Date: Sun Jan  3 03:40:59 2010
Subject: [GHC] #3801: ghc-6.10.4: internal error: PAP object entered
In-Reply-To: <047.7b8b923041b68855da236912614f1972@localhost>
References: <047.7b8b923041b68855da236912614f1972@localhost>
Message-ID: <056.de12f03633bd598abb7cd645f62eb525@localhost>

#3801: ghc-6.10.4: internal error: PAP object entered
-------------------------+--------------------------------------------------
    Reporter:  patrikja  |       Owner:               
        Type:  bug       |      Status:  new          
    Priority:  normal    |   Milestone:               
   Component:  Compiler  |     Version:  6.10.4       
  Resolution:            |    Keywords:               
          Os:  Linux     |    Testcase:               
Architecture:  x86       |     Failure:  Runtime crash
-------------------------+--------------------------------------------------
Comment (by patrikja):

 Now I've reduced the bug down to minimal dependencies - a two-line program
 still showing the same problem:
 {{{
 > import qualified Test.QuickCheck as Q
 > main = Q.quickCheck True

 patrikj@hel:~/src/gitroot/edu/AFP/Lab1_turtle$ ghc --make Main && ./Main
 [1 of 1] Compiling Main             ( Main.lhs, Main.o )
 Linking Main ...
 Main: internal error: PAP object entered!
     (GHC version 6.10.4 for i386_unknown_linux)
     Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug
 Avbruten (SIGABRT)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3801#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  3 04:54:58 2010
From: trac at galois.com (GHC)
Date: Sun Jan  3 04:28:05 2010
Subject: [GHC] #3801: ghc-6.10.4: internal error: PAP object entered
In-Reply-To: <047.7b8b923041b68855da236912614f1972@localhost>
References: <047.7b8b923041b68855da236912614f1972@localhost>
Message-ID: <056.69f64f3d827d16bc8f230adc0800cf00@localhost>

#3801: ghc-6.10.4: internal error: PAP object entered
-------------------------+--------------------------------------------------
    Reporter:  patrikja  |       Owner:               
        Type:  bug       |      Status:  new          
    Priority:  normal    |   Milestone:               
   Component:  Compiler  |     Version:  6.10.4       
  Resolution:            |    Keywords:               
          Os:  Linux     |    Testcase:               
Architecture:  x86       |     Failure:  Runtime crash
-------------------------+--------------------------------------------------
Comment (by patrikja):

 Removing the local .ghc directory (and thus the local package.conf)
 resolved my problems. Both the libstdc++ warning and the error is gone.
 This means I have solved my problem, but it still means it is possible to
 get into some kind of "bad state" package.conf-wise.

 I attach the package.conf which exhibits the problem.

 {{{
 patrikj@hel:~/src/gitroot/edu/AFP/Lab1_turtle$ ghc -package-conf
 ~/dot.ghc_20100103/i386-linux-6.10.4/package.conf -package wx --make
 Lab1_Part2_Task2
 Linking Lab1_Part2_Task2 ...
 /usr/bin/ld: warning: libstdc++.so.6, needed by
 /usr/lib/libwx_baseu-2.8.so, may conflict with libstdc++.so.7
 patrikj@hel:~/src/gitroot/edu/AFP/Lab1_turtle$ ./Lab1_Part2_Task2 0 91
 Lab1_Part2_Task2: internal error: PAP object entered!
     (GHC version 6.10.4 for i386_unknown_linux)
     Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug
 Avbruten (SIGABRT)
 }}}

 {{{
 patrikj@hel:~/src/gitroot/edu/AFP/Lab1_turtle$ ghc -package-conf
 ~/dot.ghc_20100103/i386-linux-6.10.4/package.conf --make Bug_3801 &&
 ./Bug_3801
 [1 of 1] Compiling Main             ( Bug_3801.lhs, Bug_3801.o )
 Linking Bug_3801 ...
 Bug_3801: internal error: PAP object entered!
     (GHC version 6.10.4 for i386_unknown_linux)
     Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug
 Avbruten (SIGABRT)
 }}}

 Without the "bad" package.conf it works as it should:

 {{{
 patrikj@hel:~/src/gitroot/edu/AFP/Lab1_turtle$ rm *.o *.hi
 patrikj@hel:~/src/gitroot/edu/AFP/Lab1_turtle$ ghc --make Bug_3801 &&
 ./Bug_3801
 [1 of 1] Compiling Main             ( Bug_3801.lhs, Bug_3801.o )
 Linking Bug_3801 ...
 OK, passed 100 tests.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3801#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  3 07:34:21 2010
From: trac at galois.com (GHC)
Date: Sun Jan  3 07:07:27 2010
Subject: [GHC] #597: Various error messages have inaccurate source
 locations
In-Reply-To: <047.d9b3aa24ce12758448e171cbecc1a26d@localhost>
References: <047.d9b3aa24ce12758448e171cbecc1a26d@localhost>
Message-ID: <056.a00cc1fd90fa17f9302218646de89e63@localhost>

#597: Various error messages have inaccurate source locations
-----------------------------------------+----------------------------------
  Reporter:  simonmar                    |          Owner:                  
      Type:  task                        |         Status:  new             
  Priority:  low                         |      Milestone:  _|_             
 Component:  Compiler                    |        Version:  None            
Resolution:  None                        |       Keywords:                  
Difficulty:  Moderate (less than a day)  |             Os:  Unknown/Multiple
  Testcase:                              |   Architecture:  Unknown/Multiple
   Failure:  Other                       |  
-----------------------------------------+----------------------------------
Changes (by igloo):

  * failure:  None/Unknown => Other

Comment:

 Note that to get the full span, rather than just the start, you need to
 use the `-ferror-spans` flag. I don't know why that isn't the default.

 In 6.13:

  * 1 is fixed
  * 2 is not fixed points to the entire instance declaration
  * 3 is fixed; it points to "Eq"
  * 4 is not fixed; it points to the whole type declaration, not just "A"
  * 5 is not fixed; see `fileSrcSpan` in Parser.y.pp
  * 6 is not fixed (note that the test is now readFail016)
  * 7 is not fixed points to the entire instance declaration (same as 2?)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/597#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  3 07:55:22 2010
From: trac at galois.com (GHC)
Date: Sun Jan  3 07:28:32 2010
Subject: [GHC] #3715: GHC API no longer exports location information for
 error/warning messages
In-Reply-To: <046.4e83f78284330dedbf9948985e29216e@localhost>
References: <046.4e83f78284330dedbf9948985e29216e@localhost>
Message-ID: <055.2ec14b2d37c95e9f3cb9da96e746e5c8@localhost>

#3715: GHC API no longer exports location information for error/warning messages
--------------------------------------+-------------------------------------
  Reporter:  greenrd                  |          Owner:                  
      Type:  bug                      |         Status:  new             
  Priority:  normal                   |      Milestone:  6.14.1          
 Component:  GHC API                  |        Version:  6.12.1 RC1      
Resolution:                           |       Keywords:                  
Difficulty:  Easy (less than 1 hour)  |             Os:  Unknown/Multiple
  Testcase:                           |   Architecture:  Unknown/Multiple
   Failure:  Other                    |  
--------------------------------------+-------------------------------------
Changes (by igloo):

  * owner:  igloo =>

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3715#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  3 07:57:46 2010
From: trac at galois.com (GHC)
Date: Sun Jan  3 07:30:53 2010
Subject: [GHC] #590: hsc2hs: quoting of macro arguments containing commas
In-Reply-To: <080.fa7c1970e00851ba12c0e6456c768a6f@localhost>
References: <080.fa7c1970e00851ba12c0e6456c768a6f@localhost>
Message-ID: <089.97e25fe21ea686ba650987bdb2053977@localhost>

#590: hsc2hs: quoting of macro arguments containing commas
--------------------------------------------------------+-------------------
  Reporter:  Dimitry Golubovsky <golubovsky@gmail.com>  |          Owner:  igloo           
      Type:  bug                                        |         Status:  closed          
  Priority:  low                                        |      Milestone:  Not GHC         
 Component:  hsc2hs                                     |        Version:  6.4.1           
Resolution:  fixed                                      |       Keywords:                  
Difficulty:  Unknown                                    |             Os:  Unknown/Multiple
  Testcase:  hsc2hs002                                  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown                               |  
--------------------------------------------------------+-------------------
Changes (by igloo):

  * testcase:  => hsc2hs002
  * status:  new => closed
  * resolution:  => fixed

Comment:

 Fixed by:
 {{{
 Sat Jan  2 21:52:27 GMT 2010  Ian Lynagh <igloo@earth.li>
   * make single-argument hsc2hs macros variadic; fixes trac #590
   This means that the macro works even if the argument contains a comma
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/590#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  3 08:04:04 2010
From: trac at galois.com (GHC)
Date: Sun Jan  3 07:37:11 2010
Subject: [GHC] #3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's
 value when specified C compiler to use
In-Reply-To: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost>
References: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost>
Message-ID: <051.83f6781a5ad5d7aa24ae1f47bb9d6e3e@localhost>

#3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C
compiler to use
---------------------+------------------------------------------------------
  Reporter:  nwn     |          Owner:            
      Type:  bug     |         Status:  new       
  Priority:  normal  |      Milestone:  6.14.1    
 Component:  hsc2hs  |        Version:  6.12.1 RC1
Resolution:          |       Keywords:            
Difficulty:          |             Os:  MacOS X   
  Testcase:          |   Architecture:  x86       
   Failure:  Other   |  
---------------------+------------------------------------------------------
Changes (by igloo):

  * owner:  igloo =>

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3681#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  3 08:23:21 2010
From: trac at galois.com (GHC)
Date: Sun Jan  3 07:56:29 2010
Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled?
In-Reply-To: <047.c01de827ffb9a59aafb72de68ac54369@localhost>
References: <047.c01de827ffb9a59aafb72de68ac54369@localhost>
Message-ID: <056.b59c0fad4e000a2c4b5ca68b6c190157@localhost>

#2798: Enable "rec" keyword when RecursiveDo is enabled?
---------------------------+------------------------------------------------
  Reporter:  nominolo      |          Owner:  igloo           
      Type:  task          |         Status:  closed          
  Priority:  high          |      Milestone:  6.14.1          
 Component:  Compiler      |        Version:  6.11            
Resolution:  fixed         |       Keywords:                  
Difficulty:  Unknown       |             Os:  Unknown/Multiple
  Testcase:                |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by igloo):

  * status:  new => closed
  * failure:  => None/Unknown
  * resolution:  => fixed

Comment:

 It was done for 6.12.1 after all. `RecursiveDo` is deprecated in favour of
 `DoRec`.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2798#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  3 08:23:35 2010
From: trac at galois.com (GHC)
Date: Sun Jan  3 07:56:41 2010
Subject: [GHC] #3785: Broken link in library docs
In-Reply-To: <044.21422e3934fe6a6ad246e695b17185dd@localhost>
References: <044.21422e3934fe6a6ad246e695b17185dd@localhost>
Message-ID: <053.bff260256a808c6f47de9c848a56a1d6@localhost>

#3785: Broken link in library docs
----------------------------+-----------------------------------------------
  Reporter:  igloo          |          Owner:  igloo           
      Type:  bug            |         Status:  new             
  Priority:  high           |      Milestone:  6.12.2          
 Component:  Documentation  |        Version:  6.12.1          
Resolution:                 |       Keywords:                  
Difficulty:                 |             Os:  Unknown/Multiple
  Testcase:                 |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown   |  
----------------------------+-----------------------------------------------
Comment (by igloo):

 There are also various links to the libraries from the user guide. For now
 we have symlinks in the online docs, but that isn't going to work well for
 the docs we ship for Windows. We need a plan for this.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3785#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  3 08:40:54 2010
From: trac at galois.com (GHC)
Date: Sun Jan  3 08:14:00 2010
Subject: [GHC] #3802: :main in GHCi doesn't do getArgs wildcard expansion
Message-ID: <051.9313883e0b6179d02dcd32988e44001c@localhost>

#3802: :main in GHCi doesn't do getArgs wildcard expansion
---------------------------------+------------------------------------------
    Reporter:  NeilMitchell      |       Owner:                             
        Type:  bug               |      Status:  new                        
    Priority:  normal            |   Component:  GHCi                       
     Version:  6.12.1            |    Keywords:                             
          Os:  Windows           |    Testcase:                             
Architecture:  Unknown/Multiple  |     Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------
 In GHCi, from a current directory containing some Haskell files:

 {{{
 ghci> import System
 ghci> let main = print =<< getArgs
 ghci> :main *.hs
 ["*.hs"]
 }}}

 I would have expected {{{["foo.hs","bar.hs"]}}}. Running the same thing
 from the command line (compiled or through runhaskell) gives the expected
 behaviour.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3802>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  3 13:49:44 2010
From: trac at galois.com (GHC)
Date: Sun Jan  3 13:22:50 2010
Subject: [GHC] #3802: :main in GHCi doesn't do getArgs wildcard expansion
In-Reply-To: <051.9313883e0b6179d02dcd32988e44001c@localhost>
References: <051.9313883e0b6179d02dcd32988e44001c@localhost>
Message-ID: <060.314b9cb4395d3edcf55956d81a7aaf13@localhost>

#3802: :main in GHCi doesn't do getArgs wildcard expansion
---------------------------------+------------------------------------------
    Reporter:  NeilMitchell      |       Owner:                             
        Type:  bug               |      Status:  new                        
    Priority:  normal            |   Milestone:                             
   Component:  GHCi              |     Version:  6.12.1                     
  Resolution:                    |    Keywords:                             
          Os:  Windows           |    Testcase:                             
Architecture:  Unknown/Multiple  |     Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------
Comment (by isaacdupree):

 getArgs never does wildcard expansion -- it's your shell (whichever one
 you use -- bash is common) that does it before invoking the process that
 you told it to invoke.

 (This is a common point of confusion, since it's the process's
 responsibility to deal with other things like command-line arguments.
 Bash's magic symbols to watch out for are, I believe,
 {{{
 globbing: ?*{}
 quoting: '"\
 interpolation: $`~
 pipes/multiple-commands: <>|&
 comments: #
 history (if enabled): !
 }}}

 It would be nontrivial for GHCi to copy globbing and quoting behavior, and
 impossible for it to mimic whatever-your-shell-is exactly (unless by
 invoking your shell as a subprocess. Which wouldn't really work for GHCi,
 which is meant to remain within a single ghc-process.)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3802#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  3 14:47:05 2010
From: trac at galois.com (GHC)
Date: Sun Jan  3 14:20:11 2010
Subject: [GHC] #3803: addCoverageTicksTobind should not panic when file
 location is Nothing
Message-ID: <046.170aea52f7935907ca6deb8869a6f4be@localhost>

#3803: addCoverageTicksTobind should not panic when file location is Nothing
---------------------------------+------------------------------------------
    Reporter:  clemens           |       Owner:              
        Type:  bug               |      Status:  new         
    Priority:  normal            |   Component:  Compiler    
     Version:  6.12.1            |    Keywords:  hpc         
          Os:  Unknown/Multiple  |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------
 compiler/deSugar/Coverage.lhs:
 {{{
 addCoverageTicksToBinds dflags mod mod_loc tyCons binds = do
   let orig_file =
              case ml_hs_file mod_loc of
                     Just file -> file
                     Nothing -> panic "can not find the original file
 during hpc trans"
 }}}
 Is there any reason for this function to panic? It is the only function
 (at least in my use-case) of the GHC API that panics on ms_hs_file =
 Nothing. I suggest to handle this more graceful and return emptyHpcInfo
 and emptyModBreaks just as in the case of file ending in .boot

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3803>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From iavor.diatchki at gmail.com  Sun Jan  3 22:37:22 2010
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sun Jan  3 22:10:24 2010
Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled?
In-Reply-To: <056.b59c0fad4e000a2c4b5ca68b6c190157@localhost>
References: <047.c01de827ffb9a59aafb72de68ac54369@localhost>
	<056.b59c0fad4e000a2c4b5ca68b6c190157@localhost>
Message-ID: <5ab17e791001031937k4e462df7p93770c3aa96333d@mail.gmail.com>

Hello,
so with these changes, what is the preferred way to write recursive
monadic code that will work on GHC < 6.12.1, GHC >= 6.12.1, and Hugs?
I guess, one could always fall back to just using "mfix" directly but
this seems unfortunate.
-Iavor



On Sun, Jan 3, 2010 at 5:23 AM, GHC <trac@galois.com> wrote:
> #2798: Enable "rec" keyword when RecursiveDo is enabled?
> ---------------------------+------------------------------------------------
> ?Reporter: ?nominolo ? ? ?| ? ? ? ? ?Owner: ?igloo
> ? ? ?Type: ?task ? ? ? ? ?| ? ? ? ? Status: ?closed
> ?Priority: ?high ? ? ? ? ?| ? ? ?Milestone: ?6.14.1
> ?Component: ?Compiler ? ? ?| ? ? ? ?Version: ?6.11
> Resolution: ?fixed ? ? ? ? | ? ? ? Keywords:
> Difficulty: ?Unknown ? ? ? | ? ? ? ? ? ? Os: ?Unknown/Multiple
> ?Testcase: ? ? ? ? ? ? ? ?| ? Architecture: ?Unknown/Multiple
> ? Failure: ?None/Unknown ?|
> ---------------------------+------------------------------------------------
> Changes (by igloo):
>
> ?* status: ?new => closed
> ?* failure: ?=> None/Unknown
> ?* resolution: ?=> fixed
>
> Comment:
>
> ?It was done for 6.12.1 after all. `RecursiveDo` is deprecated in favour of
> ?`DoRec`.
>
> --
> Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2798#comment:13>
> GHC <http://www.haskell.org/ghc/>
> The Glasgow Haskell Compiler
> _______________________________________________
> Glasgow-haskell-bugs mailing list
> Glasgow-haskell-bugs@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
>
>
From trac at galois.com  Mon Jan  4 03:31:15 2010
From: trac at galois.com (GHC)
Date: Mon Jan  4 03:04:19 2010
Subject: [GHC] #3788: Improved message for GHC "No instance for" Errors
In-Reply-To: <048.485a2dc2f99474a564b523723eb1f48f@localhost>
References: <048.485a2dc2f99474a564b523723eb1f48f@localhost>
Message-ID: <057.ee8b6d4115f3372f1625584e5eef4af1@localhost>

#3788: Improved message for GHC "No instance for" Errors
---------------------------+------------------------------------------------
  Reporter:  rhapsodyv     |          Owner:                  
      Type:  proposal      |         Status:  new             
  Priority:  normal        |      Milestone:                  
 Component:  Compiler      |        Version:  6.10.4          
Resolution:                |       Keywords:  errors          
Difficulty:                |             Os:  Unknown/Multiple
  Testcase:                |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by simonpj):

  * difficulty:  =>

Comment:

 Can you give a few examples of the error message you would like to see?
 That is:
  * A small program
  * The current error message
  * The error message you would prefer to have seen

 That would help me understand your suggestion.

 Thanks

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3788#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From simonpj at microsoft.com  Mon Jan  4 03:43:19 2010
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Mon Jan  4 03:16:26 2010
Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled?
In-Reply-To: <5ab17e791001031937k4e462df7p93770c3aa96333d@mail.gmail.com>
References: <047.c01de827ffb9a59aafb72de68ac54369@localhost>
	<056.b59c0fad4e000a2c4b5ca68b6c190157@localhost>
	<5ab17e791001031937k4e462df7p93770c3aa96333d@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC10AF7BFA2@DB3EX14MBXC310.europe.corp.microsoft.com>

Doesn't mdo still work?  With -XRecursiveDo?  It's deprecated, but works fine I think. The whole deprecated thing is to allow old programs to continue to work.

Simon

| -----Original Message-----
| From: glasgow-haskell-bugs-bounces@haskell.org [mailto:glasgow-haskell-bugs-
| bounces@haskell.org] On Behalf Of Iavor Diatchki
| Sent: 04 January 2010 03:37
| To: glasgow-haskell-bugs@haskell.org
| Subject: Re: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled?
| 
| Hello,
| so with these changes, what is the preferred way to write recursive
| monadic code that will work on GHC < 6.12.1, GHC >= 6.12.1, and Hugs?
| I guess, one could always fall back to just using "mfix" directly but
| this seems unfortunate.
| -Iavor
| 
| 
| 
| On Sun, Jan 3, 2010 at 5:23 AM, GHC <trac@galois.com> wrote:
| > #2798: Enable "rec" keyword when RecursiveDo is enabled?
| > ---------------------------+------------------------------------------------
| > ?Reporter: ?nominolo ? ? ?| ? ? ? ? ?Owner: ?igloo
| > ? ? ?Type: ?task ? ? ? ? ?| ? ? ? ? Status: ?closed
| > ?Priority: ?high ? ? ? ? ?| ? ? ?Milestone: ?6.14.1
| > ?Component: ?Compiler ? ? ?| ? ? ? ?Version: ?6.11
| > Resolution: ?fixed ? ? ? ? | ? ? ? Keywords:
| > Difficulty: ?Unknown ? ? ? | ? ? ? ? ? ? Os: ?Unknown/Multiple
| > ?Testcase: ? ? ? ? ? ? ? ?| ? Architecture: ?Unknown/Multiple
| > ? Failure: ?None/Unknown ?|
| > ---------------------------+------------------------------------------------
| > Changes (by igloo):
| >
| > ?* status: ?new => closed
| > ?* failure: ?=> None/Unknown
| > ?* resolution: ?=> fixed
| >
| > Comment:
| >
| > ?It was done for 6.12.1 after all. `RecursiveDo` is deprecated in favour of
| > ?`DoRec`.
| >
| > --
| > Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2798#comment:13>
| > GHC <http://www.haskell.org/ghc/>
| > The Glasgow Haskell Compiler
| > _______________________________________________
| > Glasgow-haskell-bugs mailing list
| > Glasgow-haskell-bugs@haskell.org
| > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
| >
| >
| _______________________________________________
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

From trac at galois.com  Mon Jan  4 04:08:03 2010
From: trac at galois.com (GHC)
Date: Mon Jan  4 03:41:08 2010
Subject: [GHC] #3731: SYB gone wild - mysterious <<loop>> in code
 derived from an syb-with-class example
In-Reply-To: <042.4958fc1cdd70e26a14593e01de97e65e@localhost>
References: <042.4958fc1cdd70e26a14593e01de97e65e@localhost>
Message-ID: <051.c1753f2750869a9878012f5ab17c15a7@localhost>

#3731: SYB gone wild - mysterious <<loop>> in code derived from an syb-with-class
example
------------------------------------------+---------------------------------
  Reporter:  dsf                          |          Owner:                  
      Type:  bug                          |         Status:  new             
  Priority:  normal                       |      Milestone:                  
 Component:  Compiler                     |        Version:  6.12.1          
Resolution:                               |       Keywords:                  
Difficulty:                               |             Os:  Unknown/Multiple
  Testcase:                               |   Architecture:  Unknown/Multiple
   Failure:  Incorrect result at runtime  |  
------------------------------------------+---------------------------------
Comment (by simonpj):

 I'm afraid I'm not sure when it got fixed in HEAD; indeed I am not
 entirely sure that it ''is'' properly fixed. My guess is that a snapshot
 from two or three months ago would also work.

 It'll all be part of the grand new solver, but I think that won't be ready
 for a few months.

 Let's hope you can use the HEAD, or some snapshot thereof...

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3731#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  4 06:47:54 2010
From: trac at galois.com (GHC)
Date: Mon Jan  4 06:21:07 2010
Subject: [GHC] #3716: building ghc-6.12.0.20091121 ends with internal
 Haddock or GHC error
In-Reply-To: <045.e5c85a6d9c01c90f88c47b3f6ae70039@localhost>
References: <045.e5c85a6d9c01c90f88c47b3f6ae70039@localhost>
Message-ID: <054.2fc7a0c369ca88c3cda5ed9ebdb2918e@localhost>

#3716: building ghc-6.12.0.20091121 ends with internal Haddock or GHC error
----------------------------------+-----------------------------------------
  Reporter:  maeder               |          Owner:         
      Type:  bug                  |         Status:  new    
  Priority:  normal               |      Milestone:         
 Component:  Build System         |        Version:  6.12.1 
Resolution:                       |       Keywords:         
Difficulty:                       |             Os:  Solaris
  Testcase:                       |   Architecture:  x86    
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------
Comment (by maeder):

 Replying to [comment:2 duncan]:
 > This should now be fixed by:
 > {{{
 > Thu Dec 17 01:04:21 CET 2009  Ian Lynagh <igloo@earth.li>
 >   * Fix another sed problem on Solaris
 > }}}
 >
 > Confirmation would be appreciated.

 This does not fix the problem `libraries/gen_contents_index` is now wrong
 even for other platforms (I think). The wrong line

 {{{
         VERSION=`grep -i '^version:' $LIBPATH/$NAME.cabal | sed 's/.*://'`
 | tr -d ' \t'
 }}}

 should be replaced by:

 {{{
         VERSION=`grep -i '^version:' $LIBPATH/$NAME.cabal | sed 's/.*://'
 | tr -d ' \t'`
 }}}

 (Apologies, if my previous comment was less clear)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3716#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  4 07:02:48 2010
From: trac at galois.com (GHC)
Date: Mon Jan  4 06:35:51 2010
Subject: [GHC] #3804: strange output of mkGHCConstants on SunOS 5.8/sparc
Message-ID: <042.aa6d3bd949f1a02a1e301e5062530c41@localhost>

#3804: strange output of mkGHCConstants on SunOS 5.8/sparc
------------------------+---------------------------------------------------
    Reporter:  CBa      |       Owner:                     
        Type:  bug      |      Status:  new                
    Priority:  normal   |   Component:  Build System       
     Version:  6.12.1   |    Keywords:                     
          Os:  Solaris  |    Testcase:                     
Architecture:  sparc    |     Failure:  Building GHC failed
------------------------+---------------------------------------------------
 mkGHCConstants generates a file with:



 oFFSET_StgRegTable_rR1 :: Int[[BR]]
 oFFSET_StgRegTable_rR1 = zd[[BR]]
 oFFSET_StgRegTable_rR2 :: Int[[BR]]
 oFFSET_StgRegTable_rR2 = zd[[BR]]
 ...



 whatever zd is. My bootstrap-ghc is 6.8.3.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3804>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  4 08:19:09 2010
From: trac at galois.com (GHC)
Date: Mon Jan  4 07:52:13 2010
Subject: [GHC] #3787: GHC 6.12.1 panic
In-Reply-To: <047.0ece8a101cc798eefac149b629f279fa@localhost>
References: <047.0ece8a101cc798eefac149b629f279fa@localhost>
Message-ID: <056.fd3dd8f058379a37dfc3b1a6d5e3b412@localhost>

#3787: GHC 6.12.1 panic
---------------------------------+------------------------------------------
  Reporter:  blamario            |          Owner:  simonmar      
      Type:  bug                 |         Status:  new           
  Priority:  high                |      Milestone:  6.12.2        
 Component:  Compiler            |        Version:  6.12.1        
Resolution:                      |       Keywords:  panic         
Difficulty:                      |             Os:  Linux         
  Testcase:                      |   Architecture:  x86_64 (amd64)
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Comment (by simonpj):

 Thank you for boiling this down.  If you compile with `-dcore-lint` you'll
 see that the typechecker is constructing an ill-typed program.  I'm not
 sure why yet.

 I don't know whether that is the cause of the `nameModule` error, but I
 suppose it could be.

 As it happens I plan to work on the type-inference engine (and the
 constraint solver in particular) over the next two or three months, so
 I'll fix it as part of that sweep.

 Meanwhile, the problem is associated with contexts that have equalities in
 them, eg:
 {{{
 resolveProducerConsumer
   :: forall a s s0 t t' m x.
      (Functor s0, Monad m, s ~ SomeFunctor (TryYield a) (Await (Maybe a)),
       t ~ Trampoline (EitherFunctor s0 s) m x) =>
      s t -> t
 }}}
 You can get rid of these easily by replacing `s` by `(SomeFunctor
 (TryYield a) (Await (Maybe a)))`, and similarly for `t`.  I tried this,
 and it worked.

 Meanwhile I'll keep the test -- thank you!

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3787#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  4 08:22:05 2010
From: trac at galois.com (GHC)
Date: Mon Jan  4 07:55:07 2010
Subject: [GHC] #3799: undefined symbols and undefined references
 possibly related to template haskell
In-Reply-To: <049.4a0311c347285cc6754ed4f6a532bc0a@localhost>
References: <049.4a0311c347285cc6754ed4f6a532bc0a@localhost>
Message-ID: <058.52b508f21892ed6ef7137c7f3cf4cced@localhost>

#3799: undefined symbols and undefined references possibly related to template
haskell
---------------------------------+------------------------------------------
  Reporter:  JeremyShaw          |          Owner:                                               
      Type:  bug                 |         Status:  new                                          
  Priority:  normal              |      Milestone:                                               
 Component:  Compiler            |        Version:  6.12.1                                       
Resolution:                      |       Keywords:  undefined symbols references template haskell
Difficulty:                      |             Os:  Unknown/Multiple                             
  Testcase:                      |   Architecture:  Unknown/Multiple                             
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Comment (by simonpj):

 Another common factor is that all the missing things look like
 {{{
 sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure
 }}}
 Or possibly `dataType` instead of `constr`.  Undoing the z-encoding we
 get:
 {{{
 syb-with-
 class-0.6.1_Data.Generics.SYB.WithClass.Instances_constr[ad6f]_closure
 }}}
 And indeed, I download `syb-with-class` and compile `Instances` with
 `-ddump-splices` I see
 {{{
 Data/Generics/SYB/WithClass/Instances.hs:1:0:
     Data/Generics/SYB/WithClass/Instances.hs:1:0: Splicing declarations
         deriveData ['ByteString]
       ======>
         Data/Generics/SYB/WithClass/Instances.hs:726:3-27
         constr[a2YC] :: Constr
         constr[a2YC] = mkConstr dataType[a2YB] "PS" "" Prefix
         dataType[a2YB] :: DataType
         dataType[a2YB] = mkDataType "ByteString" [constr[a2YC]]
 }}}
 Those are pretty weird names for top-level bindings!  But still, it should
 work fine, because they are only used via the instance declaration.

 But it does make me wonder: could you have compiled syb-with-class twice?
 Each time you compile it you could potentially get different names.

 If it happens repeatably, do
 {{{
 ghc --show-iface Instances.hi
 }}}
 where the `Instances.hi` file is the one from the syb-with-class package.
 Check the names of the top level bindings (as above).  Are they the same
 as you see with `nm Instances.o`?

 Now when compiling `Server.hs` (which gets the offending symbols), use
 `-ddump-if-trace` to see what interface files it is loading, and check
 that it loads the correct `Instances.hi`.

 Does the same thing happen in file-at-a-time batch mode, or just with
 `--make`?

 Somehow or other, I bet that you are getting two different `Instances.hi`
 files, or an `Instances.hi` that does not line up with the `Instances.o`.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  4 08:24:30 2010
From: trac at galois.com (GHC)
Date: Mon Jan  4 07:57:33 2010
Subject: [GHC] #3796: GHC 6.12 dependency checking many times slower
 than 6.10
In-Reply-To: <048.1804574c402b028604cc65b754fd78d4@localhost>
References: <048.1804574c402b028604cc65b754fd78d4@localhost>
Message-ID: <057.448372b29cc0422fd6c128d976e21a20@localhost>

#3796: GHC 6.12 dependency checking many times slower than 6.10
-------------------------------------------+--------------------------------
  Reporter:  sunrayser                     |          Owner:  simonmar
      Type:  bug                           |         Status:  new     
  Priority:  high                          |      Milestone:  6.12.2  
 Component:  Compiler                      |        Version:  6.12.1  
Resolution:                                |       Keywords:          
Difficulty:                                |             Os:  Linux   
  Testcase:                                |   Architecture:  x86     
   Failure:  Compile-time performance bug  |  
-------------------------------------------+--------------------------------
Comment (by simonpj):

 Simon's looked into this:
 {{{
 Thu Dec 31 16:46:51 GMT 2009  Simon Marlow <marlowsd@gmail.com>
   * Rolling back: Make FastString thread-safe.
   Ignore-this: 8f21b256b0c86d167f8f6984d2b27a87

   This patch was the cause of the compile-time performance regression in
   #3796.  My guess is that it is due to the use of unsafePerformIO which
   traverses the stack up to the first update frame, and perhaps we have
   a deep stack when reading the dictionary from a .hi file.  In any
   case, since we're not relying on thread safety for FastStrings, I
   think the safest thing to do is back this out until we can investigate
   further.
 }}}
 I'm not sure if we can close the ticket.  Simon?

 S

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3796#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  4 09:32:14 2010
From: trac at galois.com (GHC)
Date: Mon Jan  4 09:05:16 2010
Subject: [GHC] #3783: Allow --make and --fno-code
In-Reply-To: <045.a0b0f64377b1a823678cd323636fb6d7@localhost>
References: <045.a0b0f64377b1a823678cd323636fb6d7@localhost>
Message-ID: <054.87925f1a3809ca60db980150cbdeb0e7@localhost>

#3783: Allow --make and --fno-code
------------------------------+---------------------------------------------
  Reporter:  duncan           |          Owner:  simonmar        
      Type:  feature request  |         Status:  new             
  Priority:  normal           |      Milestone:  6.14.1          
 Component:  Compiler         |        Version:  6.12.1          
Resolution:                   |       Keywords:                  
Difficulty:                   |             Os:  Unknown/Multiple
  Testcase:                   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown     |  
------------------------------+---------------------------------------------
Changes (by simonpj):

  * owner:  => simonmar

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3783#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  4 12:12:21 2010
From: trac at galois.com (GHC)
Date: Mon Jan  4 11:45:23 2010
Subject: [GHC] #3802: :main in GHCi doesn't do getArgs wildcard expansion
In-Reply-To: <051.9313883e0b6179d02dcd32988e44001c@localhost>
References: <051.9313883e0b6179d02dcd32988e44001c@localhost>
Message-ID: <060.ce114b145f28ce29c6edfca9d559f509@localhost>

#3802: :main in GHCi doesn't do getArgs wildcard expansion
---------------------------------+------------------------------------------
    Reporter:  NeilMitchell      |       Owner:                             
        Type:  bug               |      Status:  new                        
    Priority:  normal            |   Milestone:                             
   Component:  GHCi              |     Version:  6.12.1                     
  Resolution:                    |    Keywords:                             
          Os:  Windows           |    Testcase:                             
Architecture:  Unknown/Multiple  |     Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------
Comment (by NeilMitchell):

 Actually, in Windows I believe it is GHC that does the wildcard expansion
 - not the shell. Either way, the intention of :main is to test the program
 as though you were running it from the command line, which means that
 getArgs should really do the expansion.

 I am happy for this to be a Windows only fix, or for it to use the Windows
 expansion GHC defaults to on all platforms. For Unix you could always do
 system ("echo " ++ args) or some similar clever shell trick to expand the
 arguments.

 This bug was seriously confusing to a beginner (on whose behalf I'm
 reporting this).

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3802#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  4 12:22:23 2010
From: trac at galois.com (GHC)
Date: Mon Jan  4 11:55:25 2010
Subject: [GHC] #3802: :main in GHCi doesn't do getArgs wildcard expansion
In-Reply-To: <051.9313883e0b6179d02dcd32988e44001c@localhost>
References: <051.9313883e0b6179d02dcd32988e44001c@localhost>
Message-ID: <060.56b7bfd64596e1af2bcc4958ce85551d@localhost>

#3802: :main in GHCi doesn't do getArgs wildcard expansion
------------------------------------------+---------------------------------
  Reporter:  NeilMitchell                 |          Owner:                  
      Type:  bug                          |         Status:  new             
  Priority:  normal                       |      Milestone:                  
 Component:  GHCi                         |        Version:  6.12.1          
Resolution:                               |       Keywords:                  
Difficulty:                               |             Os:  Windows         
  Testcase:                               |   Architecture:  Unknown/Multiple
   Failure:  Incorrect result at runtime  |  
------------------------------------------+---------------------------------
Changes (by igloo):

  * difficulty:  =>

Comment:

 For non-Windows, I'd say the current behaviour is right.

 For Windows, I'm not sure what I think.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3802#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From iavor.diatchki at gmail.com  Mon Jan  4 14:52:51 2010
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon Jan  4 14:25:52 2010
Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled?
In-Reply-To: <59543203684B2244980D7E4057D5FBC10AF7BFA2@DB3EX14MBXC310.europe.corp.microsoft.com>
References: <047.c01de827ffb9a59aafb72de68ac54369@localhost>
	<056.b59c0fad4e000a2c4b5ca68b6c190157@localhost>
	<5ab17e791001031937k4e462df7p93770c3aa96333d@mail.gmail.com>
	<59543203684B2244980D7E4057D5FBC10AF7BFA2@DB3EX14MBXC310.europe.corp.microsoft.com>
Message-ID: <5ab17e791001041152r6c4a3096rb0edfb249f79d84a@mail.gmail.com>

Hello,

I hope that it does but I have not installed GHC 6.12 yet.  I was
wondering more how to write new programs that are not restricted to
work only with GHC >= 6.12.1.  Sometimes one can make things portable
with a bit of CPP---not pretty but it works---but, in this case, I
could not think of a good way to do this, so if anyone has ideas...

-Iavor

PS:  I sympathize with the desire to avoid having two ways of doing
the same thing in the long run, but it would have been nice to have
both features in an official release so that we could compare them
both in practice before the one got deprecated.



On Mon, Jan 4, 2010 at 12:43 AM, Simon Peyton-Jones
<simonpj@microsoft.com> wrote:
> Doesn't mdo still work? ?With -XRecursiveDo? ?It's deprecated, but works fine I think. The whole deprecated thing is to allow old programs to continue to work.
>
> Simon
>
> | -----Original Message-----
> | From: glasgow-haskell-bugs-bounces@haskell.org [mailto:glasgow-haskell-bugs-
> | bounces@haskell.org] On Behalf Of Iavor Diatchki
> | Sent: 04 January 2010 03:37
> | To: glasgow-haskell-bugs@haskell.org
> | Subject: Re: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled?
> |
> | Hello,
> | so with these changes, what is the preferred way to write recursive
> | monadic code that will work on GHC < 6.12.1, GHC >= 6.12.1, and Hugs?
> | I guess, one could always fall back to just using "mfix" directly but
> | this seems unfortunate.
> | -Iavor
> |
> |
> |
> | On Sun, Jan 3, 2010 at 5:23 AM, GHC <trac@galois.com> wrote:
> | > #2798: Enable "rec" keyword when RecursiveDo is enabled?
> | > ---------------------------+------------------------------------------------
> | > ?Reporter: ?nominolo ? ? ?| ? ? ? ? ?Owner: ?igloo
> | > ? ? ?Type: ?task ? ? ? ? ?| ? ? ? ? Status: ?closed
> | > ?Priority: ?high ? ? ? ? ?| ? ? ?Milestone: ?6.14.1
> | > ?Component: ?Compiler ? ? ?| ? ? ? ?Version: ?6.11
> | > Resolution: ?fixed ? ? ? ? | ? ? ? Keywords:
> | > Difficulty: ?Unknown ? ? ? | ? ? ? ? ? ? Os: ?Unknown/Multiple
> | > ?Testcase: ? ? ? ? ? ? ? ?| ? Architecture: ?Unknown/Multiple
> | > ? Failure: ?None/Unknown ?|
> | > ---------------------------+------------------------------------------------
> | > Changes (by igloo):
> | >
> | > ?* status: ?new => closed
> | > ?* failure: ?=> None/Unknown
> | > ?* resolution: ?=> fixed
> | >
> | > Comment:
> | >
> | > ?It was done for 6.12.1 after all. `RecursiveDo` is deprecated in favour of
> | > ?`DoRec`.
> | >
> | > --
> | > Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2798#comment:13>
> | > GHC <http://www.haskell.org/ghc/>
> | > The Glasgow Haskell Compiler
> | > _______________________________________________
> | > Glasgow-haskell-bugs mailing list
> | > Glasgow-haskell-bugs@haskell.org
> | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
> | >
> | >
> | _______________________________________________
> | Glasgow-haskell-bugs mailing list
> | Glasgow-haskell-bugs@haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
>
>
From trac at galois.com  Mon Jan  4 19:37:42 2010
From: trac at galois.com (GHC)
Date: Mon Jan  4 19:10:44 2010
Subject: [GHC] #3805: Bad error message "Invalid type signature"
Message-ID: <048.004edd9052a06de1691de17f973fb7d3@localhost>

#3805: Bad error message "Invalid type signature"
---------------------------------+------------------------------------------
    Reporter:  asuffield         |       Owner:                   
        Type:  bug               |      Status:  new              
    Priority:  normal            |   Component:  Compiler (Parser)
     Version:  6.12.1            |    Keywords:                   
          Os:  Unknown/Multiple  |    Testcase:                   
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown     
---------------------------------+------------------------------------------
 The following line of code:

 {{{foreign export ccall foo :: IO ()}}}

 generates this error message:

 {{{TestErr.hs:1:0: Invalid type signature}}}

 (In this case, the programmer error was of course that the
 !ForeignFunctionInterface pragma is missing, and the parser has treated
 this as a definition of the function 'foreign'; this is a motivational
 example and not directly relevant to the issue)

 This error message is quite uninformative - and after looking at the code
 which generates it, I still can't figure out what kind of error it's
 supposed to be detecting. It should be changed to explain why the type
 signature appears to be invalid. Ideally, it would then be immediately
 apparent that the line has been parsed in an unexpected way.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3805>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  4 20:38:36 2010
From: trac at galois.com (GHC)
Date: Mon Jan  4 20:11:36 2010
Subject: [GHC] #3806: Type checking errors in foreign declarations reported
 at wrong locations
Message-ID: <048.1e6b813747b0afcaa48160f966948c03@localhost>

#3806: Type checking errors in foreign declarations reported at wrong locations
---------------------------------+------------------------------------------
    Reporter:  asuffield         |       Owner:              
        Type:  bug               |      Status:  new         
    Priority:  normal            |   Component:  Compiler    
     Version:  6.12.1            |    Keywords:              
          Os:  Unknown/Multiple  |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------
 The following code:
 {{{
 {-# LANGUAGE ForeignFunctionInterface #-}
 import Foreign.C.Types

 foreign export ccall foo :: CInt -> IO ()
 foo "x" = return ()
 }}}

 yields this error:

 {{{
 TestErr.hs:4:0:
     Couldn't match expected type `CInt' against inferred type `[Char]'
     In the expression: foo
     When checking declaration:
         foreign export ccall "foo" foo :: CInt -> IO ()
 }}}

 The error part is notionally correct, but the location where it is
 reported is wrong - it's reporting the type declaration as erroneous,
 while type errors would normally report the function definition.

 Compare the error with a non-foreign declaration:

 {{{
 {-# LANGUAGE ForeignFunctionInterface #-}
 import Foreign.C.Types

 foo :: CInt -> IO ()
 foo "x" = return ()
 }}}

 giving:

 {{{
 TestErr.hs:5:4:
     Couldn't match expected type `CInt' against inferred type `[Char]'
     In the pattern: "x"
     In the definition of `foo': foo "x" = return ()
 }}}

 This is the error that I wanted to see.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3806>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  4 21:41:11 2010
From: trac at galois.com (GHC)
Date: Mon Jan  4 21:14:10 2010
Subject: [GHC] #3806: Type checking errors in foreign declarations
 reported at wrong locations
In-Reply-To: <048.1e6b813747b0afcaa48160f966948c03@localhost>
References: <048.1e6b813747b0afcaa48160f966948c03@localhost>
Message-ID: <057.a17faa0d09f3e15cf626e1eec09a8e82@localhost>

#3806: Type checking errors in foreign declarations reported at wrong locations
---------------------------------+------------------------------------------
    Reporter:  asuffield         |       Owner:              
        Type:  bug               |      Status:  new         
    Priority:  normal            |   Milestone:              
   Component:  Compiler          |     Version:  6.12.1      
  Resolution:                    |    Keywords:              
          Os:  Unknown/Multiple  |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------
Comment (by asuffield):

 Addendum: to be clear, this happens because foreign export statements
 aren't type constraints on the function, but rather create new instances
 of the function with the given type. The semantics are fine, I just want
 the error message to indicate the location of the other part of the
 problem. On reflection, this may be non-trivial to accomplish.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3806#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From simonpj at microsoft.com  Tue Jan  5 03:00:31 2010
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue Jan  5 02:33:58 2010
Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled?
In-Reply-To: <5ab17e791001041152r6c4a3096rb0edfb249f79d84a@mail.gmail.com>
References: <047.c01de827ffb9a59aafb72de68ac54369@localhost>
	<056.b59c0fad4e000a2c4b5ca68b6c190157@localhost>
	<5ab17e791001031937k4e462df7p93770c3aa96333d@mail.gmail.com>
	<59543203684B2244980D7E4057D5FBC10AF7BFA2@DB3EX14MBXC310.europe.corp.microsoft.com>
	<5ab17e791001041152r6c4a3096rb0edfb249f79d84a@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC10AF7CCB4@DB3EX14MBXC310.europe.corp.microsoft.com>

| I hope that it does but I have not installed GHC 6.12 yet.  I was
| wondering more how to write new programs that are not restricted to
| work only with GHC >= 6.12.1.  Sometimes one can make things portable
| with a bit of CPP---not pretty but it works---but, in this case, I
| could not think of a good way to do this, so if anyone has ideas...

Yes you can.  Since nothing except 6.12 has 'rec', you can use 'mdo'.  If you don't want the deprecation warning use -fno-warn-deprecations.

Of course *any* feature removal is going to lead to programs that used to work not working any more.  I don't see how to avoid that, except by keeping all features forever.  We can keep mdo as long as necessary, I suppose, but I'd like some mechanism to gently encourage people to the rec syntax, which is what the deprecation warning should do.

Simon
From trac at galois.com  Tue Jan  5 03:21:36 2010
From: trac at galois.com (GHC)
Date: Tue Jan  5 02:54:35 2010
Subject: [GHC] #3805: Bad error message "Invalid type signature"
In-Reply-To: <048.004edd9052a06de1691de17f973fb7d3@localhost>
References: <048.004edd9052a06de1691de17f973fb7d3@localhost>
Message-ID: <057.5b8019f035539fdd4ffe2690bf3074f9@localhost>

#3805: Bad error message "Invalid type signature"
--------------------------------+-------------------------------------------
  Reporter:  asuffield          |          Owner:                  
      Type:  bug                |         Status:  new             
  Priority:  normal             |      Milestone:                  
 Component:  Compiler (Parser)  |        Version:  6.12.1          
Resolution:                     |       Keywords:                  
Difficulty:                     |             Os:  Unknown/Multiple
  Testcase:                     |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown       |  
--------------------------------+-------------------------------------------
Changes (by simonpj):

  * difficulty:  =>

Comment:

 Can you say what would be better?

 GHC parses
 {{{
 <expr> :: <type>
 }}}
 and then rejects the program with the above message if `<expr>` is not a
 plain variable.  (You may ask why it isn't just `<variable>` on the left
 then.  There's a good reason, but if we had `<variable>` on the left you'd
 just get the even more uninformative message "`Parse error`".)

 What would you ''like'' the message to say?  "Parse error in type
 signature"?  Or what?

 Regardless of your answer, it might be cool to spot cases which start with
 "`foreign`" and suggest the appropriate flag.  But what if you said
 {{{
 f g :: Int
 }}}
 having perhaps mis-typed "`f,g::Int`"?

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3805#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  5 03:39:40 2010
From: trac at galois.com (GHC)
Date: Tue Jan  5 03:12:38 2010
Subject: [GHC] #3806: Type checking errors in foreign declarations
 reported at wrong locations
In-Reply-To: <048.1e6b813747b0afcaa48160f966948c03@localhost>
References: <048.1e6b813747b0afcaa48160f966948c03@localhost>
Message-ID: <057.76792094afa0faf17cdfc47bf1d836b2@localhost>

#3806: Type checking errors in foreign declarations reported at wrong locations
---------------------------+------------------------------------------------
  Reporter:  asuffield     |          Owner:                  
      Type:  bug           |         Status:  closed          
  Priority:  normal        |      Milestone:                  
 Component:  Compiler      |        Version:  6.12.1          
Resolution:  invalid       |       Keywords:                  
Difficulty:                |             Os:  Unknown/Multiple
  Testcase:                |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by simonpj):

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

Comment:

 I see your point, but  your follow-up remark hits the nail on the head.
 It's fine, for example, to say this:
 {{{
 module M where

 import Foo( foo1 )

 newtype Blip = MkBlip { foo2 :: CInt }

 class Flop a where
   foo3 :: a -> IO ()
 instance Flop CInt where ...

 foreign export ccall foo1 :: CInt -> IO ()
 foreign export ccall foo2 :: Blip -> IO ()
 foreign export ccall foo3 :: CInt -> IO ()
 }}}
 All three are fine.  See Section 3.4 in
 http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise3.html#x6-100003.

 In short, a `foreign export` is not a type signature at all.  It's a
 ''use'' of `foo`.

 An alternative design would be:
  * `foreign export foo` really is a type signature for `foo`
  * A `foreign export foo` must be accompanied by a top-level definition of
 `foo` in the same module.
 On the whole I think that might be a better design.  It would be simpler,
 and I don't think the above cases are important in practice.  But that
 would mean changing the FFI spec.

 I'll close the GHC ticket as invalid, but there's a possible discussion to
 be had about what the FFI spec should say.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3806#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  5 04:11:58 2010
From: trac at galois.com (GHC)
Date: Tue Jan  5 03:45:03 2010
Subject: [GHC] #3796: GHC 6.12 dependency checking many times slower
 than 6.10
In-Reply-To: <048.1804574c402b028604cc65b754fd78d4@localhost>
References: <048.1804574c402b028604cc65b754fd78d4@localhost>
Message-ID: <057.a1f7fedef0c1ae0cb7612ffc4a799b96@localhost>

#3796: GHC 6.12 dependency checking many times slower than 6.10
-------------------------------------------+--------------------------------
  Reporter:  sunrayser                     |          Owner:  igloo 
      Type:  merge                         |         Status:  new   
  Priority:  high                          |      Milestone:  6.12.2
 Component:  Compiler                      |        Version:  6.12.1
Resolution:                                |       Keywords:        
Difficulty:                                |             Os:  Linux 
  Testcase:                                |   Architecture:  x86   
   Failure:  Compile-time performance bug  |  
-------------------------------------------+--------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * type:  bug => merge

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3796#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  5 04:43:38 2010
From: trac at galois.com (GHC)
Date: Tue Jan  5 04:16:39 2010
Subject: [GHC] #3789: Segfault and -dstg-lint errors using FFI and
 -XEmptyDataDecls
In-Reply-To: <045.2c0f987a4ddd3ec0b9fa039bca72f39b@localhost>
References: <045.2c0f987a4ddd3ec0b9fa039bca72f39b@localhost>
Message-ID: <054.b4bca07ab1dcd88b5672e5b8d8c6ac00@localhost>

#3789: Segfault and -dstg-lint errors using FFI and -XEmptyDataDecls
-----------------------------+----------------------------------------------
  Reporter:  judahj          |          Owner:         
      Type:  bug             |         Status:  new    
  Priority:  high            |      Milestone:  6.12.2 
 Component:  Compiler (NCG)  |        Version:  6.12.1 
Resolution:                  |       Keywords:         
Difficulty:                  |             Os:  MacOS X
  Testcase:                  |   Architecture:  x86    
   Failure:  Runtime crash   |  
-----------------------------+----------------------------------------------
Comment (by simonpj):

 I'm afraid the STG Lint failures reflect a bug in STG Lint, not in the
 program.  I've fixed STG Lint:
 {{{
 Mon Jan  4 13:46:59 PST 2010  simonpj@microsoft.com
   * Fix bugs in STG Lint

   The Stg Lint failure reported in Trac #3789 were bogus.
   This patch fixes STG Lint, which must have been unused
   for ages.

     M ./compiler/stgSyn/StgLint.lhs -18 +13
 }}}
 However, the underlying seg-fault is unaffected.  Since it happens with
 `-fasm` but not with `-fvia-C` it must be in the code generator.

 I believe that the machine code (and STG code) generated from `type Foo_ =
 ()` and `data Foo_` should be identical.  A good first step would be to
 see how they differ.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3789#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  5 04:45:51 2010
From: trac at galois.com (GHC)
Date: Tue Jan  5 04:19:01 2010
Subject: [GHC] #3792: Qualified names in import specifications
In-Reply-To: <044.0afdfc1c49ec255d82e9097f816e7649@localhost>
References: <044.0afdfc1c49ec255d82e9097f816e7649@localhost>
Message-ID: <053.804b7485c35b050d14d18f549a733919@localhost>

#3792: Qualified names in import specifications
---------------------------------------+------------------------------------
  Reporter:  nibro                     |          Owner:  igloo           
      Type:  merge                     |         Status:  new             
  Priority:  normal                    |      Milestone:                  
 Component:  Compiler                  |        Version:  6.12.1          
Resolution:                            |       Keywords:                  
Difficulty:                            |             Os:  Unknown/Multiple
  Testcase:  rename/should_fail/T3792  |   Architecture:  Unknown/Multiple
   Failure:  Other                     |  
---------------------------------------+------------------------------------
Changes (by simonpj):

  * testcase:  => rename/should_fail/T3792
  * difficulty:  =>
  * type:  bug => merge
  * owner:  => igloo

Comment:

 Quite right, thank you.  I've fixed this and added a test:
 {{{
 Mon Jan  4 13:59:50 PST 2010  simonpj@microsoft.com
   * Fix Trac #3792: check for qualified names in import items

     M ./compiler/rename/RnNames.lhs -4 +9
 }}}
 Merge to 6.21 branch, please.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3792#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  5 07:25:24 2010
From: trac at galois.com (GHC)
Date: Tue Jan  5 06:58:24 2010
Subject: [GHC] #3805: Bad error message "Invalid type signature"
In-Reply-To: <048.004edd9052a06de1691de17f973fb7d3@localhost>
References: <048.004edd9052a06de1691de17f973fb7d3@localhost>
Message-ID: <057.7b23bb45458946167ed90ada8ad8de00@localhost>

#3805: Bad error message "Invalid type signature"
--------------------------------+-------------------------------------------
  Reporter:  asuffield          |          Owner:                  
      Type:  bug                |         Status:  new             
  Priority:  normal             |      Milestone:                  
 Component:  Compiler (Parser)  |        Version:  6.12.1          
Resolution:                     |       Keywords:                  
Difficulty:                     |             Os:  Unknown/Multiple
  Testcase:                     |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown       |  
--------------------------------+-------------------------------------------
Comment (by asuffield):

 Basically the message needs to indicate the information in your comment,
 and show that the parser is using an unintended interpretation. To spot
 the error quickly, the programmer needs to know the lexemes that got
 unexpectedly grabbed by the :: and what the parser was expecting to see.
 Something along these lines:

 {{{
 TestErr.hs:1:0: Invalid type signature: `f g' is not a plain variable name
 }}}

 (Personally, I spent a good ten minutes of head-scratching before
 realising that it was complaining about the term, not the type)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3805#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  5 07:53:51 2010
From: trac at galois.com (GHC)
Date: Tue Jan  5 07:26:49 2010
Subject: [GHC] #3805: Bad error message "Invalid type signature"
In-Reply-To: <048.004edd9052a06de1691de17f973fb7d3@localhost>
References: <048.004edd9052a06de1691de17f973fb7d3@localhost>
Message-ID: <057.2b58706f7524f7347b80a8c677fb0587@localhost>

#3805: Bad error message "Invalid type signature"
--------------------------------+-------------------------------------------
  Reporter:  asuffield          |          Owner:                  
      Type:  bug                |         Status:  new             
  Priority:  normal             |      Milestone:                  
 Component:  Compiler (Parser)  |        Version:  6.12.1          
Resolution:                     |       Keywords:                  
Difficulty:                     |             Os:  Unknown/Multiple
  Testcase:                     |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown       |  
--------------------------------+-------------------------------------------
Comment (by igloo):

 I think part of the problem is that it is ambiguous whether "type
 signature" refers to `e :: t` (in which case it is "invalid") or `:: t`
 (in which case it is "unexpected").

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3805#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  5 17:27:34 2010
From: trac at galois.com (GHC)
Date: Tue Jan  5 17:00:50 2010
Subject: [GHC] #3637: ./configure doesn't understand Gentoo's
 build/host/target
In-Reply-To: <047.fcebd5e462086e021124f01f2c19fc8c@localhost>
References: <047.fcebd5e462086e021124f01f2c19fc8c@localhost>
Message-ID: <056.501db8641458106cdffe0aacde94c56b@localhost>

#3637: ./configure doesn't understand Gentoo's build/host/target
----------------------------------+-----------------------------------------
  Reporter:  kolmodin             |          Owner:                  
      Type:  bug                  |         Status:  new             
  Priority:  high                 |      Milestone:  6.12.2          
 Component:  Build System         |        Version:  6.12.1 RC1      
Resolution:                       |       Keywords:  regression      
Difficulty:  Unknown              |             Os:  Unknown/Multiple
  Testcase:                       |   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------
Comment (by asuffield):

 Here's a first cut at a solution. The central issue is that ghc has its
 own set of configuration names that are not precisely the same as gnu ones
 (this is unfortunate). What I did here was to:

  * Restore the autoconf macros that work out canonical gnu configuration
 names, which were removed in 6.12
  * ...but for the autodetection case, use the names from the bootstrapping
 ghc rather than autoconf; hence, the macros are used only to process
 arguments given to configure. This preserves the fixes to #1717 and #2951
  * Add some macros that convert from gnu names to ghc ones; these should
 be considerably more robust than the old stuff from 6.10

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3637#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  5 18:21:10 2010
From: trac at galois.com (GHC)
Date: Tue Jan  5 17:54:08 2010
Subject: [GHC] #3731: SYB gone wild - mysterious <<loop>> in code
 derived from an syb-with-class example
In-Reply-To: <042.4958fc1cdd70e26a14593e01de97e65e@localhost>
References: <042.4958fc1cdd70e26a14593e01de97e65e@localhost>
Message-ID: <051.d215b95e5937c17c2549a46814189a94@localhost>

#3731: SYB gone wild - mysterious <<loop>> in code derived from an syb-with-class
example
------------------------------------------+---------------------------------
  Reporter:  dsf                          |          Owner:                  
      Type:  bug                          |         Status:  new             
  Priority:  normal                       |      Milestone:                  
 Component:  Compiler                     |        Version:  6.13            
Resolution:                               |       Keywords:                  
Difficulty:                               |             Os:  Unknown/Multiple
  Testcase:                               |   Architecture:  Unknown/Multiple
   Failure:  Incorrect result at runtime  |  
------------------------------------------+---------------------------------
Changes (by dsf):

  * version:  6.12.1 => 6.13

Comment:

 Ok, we have managed to make our way to HEAD!  This did indeed resolve the
 problem in Bug.hs.  However, a very similar issue still affects our
 application (as you suggested it might), and the example, which I have
 named Bug2.hs, is attached.  It still refers to some Happstack modules, if
 it would be helpful we could expand it so that those imports go away.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3731#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  6 12:15:35 2010
From: trac at galois.com (GHC)
Date: Wed Jan  6 11:48:34 2010
Subject: [GHC] #3805: Bad error message "Invalid type signature"
In-Reply-To: <048.004edd9052a06de1691de17f973fb7d3@localhost>
References: <048.004edd9052a06de1691de17f973fb7d3@localhost>
Message-ID: <057.30aba0ca5a9aa420531ec2377f355315@localhost>

#3805: Bad error message "Invalid type signature"
--------------------------------+-------------------------------------------
  Reporter:  asuffield          |          Owner:                  
      Type:  bug                |         Status:  new             
  Priority:  normal             |      Milestone:                  
 Component:  Compiler (Parser)  |        Version:  6.12.1          
Resolution:                     |       Keywords:                  
Difficulty:                     |             Os:  Unknown/Multiple
  Testcase:                     |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown       |  
--------------------------------+-------------------------------------------
Comment (by simonpj):

 Ah I see.  I think I'll make it say
 {{{
 TestErr.hs:1:0: Invalid type signature: should be of form <variable> ::
 <type>
 }}}
 That should be an improvement. And if "foreign" is the first word (ie your
 original example).
 {{{
 TestErr.hs:1:0:
   Invalid type signature; perhaps you meant to use
 -XForeignFunctionInterface
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3805#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  6 13:27:30 2010
From: trac at galois.com (GHC)
Date: Wed Jan  6 13:00:28 2010
Subject: [GHC] #3802: :main in GHCi doesn't do getArgs wildcard expansion
In-Reply-To: <051.9313883e0b6179d02dcd32988e44001c@localhost>
References: <051.9313883e0b6179d02dcd32988e44001c@localhost>
Message-ID: <060.70d637a60e46dea638eac8a50dce06e1@localhost>

#3802: :main in GHCi doesn't do getArgs wildcard expansion
------------------------------------------+---------------------------------
  Reporter:  NeilMitchell                 |          Owner:                  
      Type:  bug                          |         Status:  new             
  Priority:  normal                       |      Milestone:                  
 Component:  GHCi                         |        Version:  6.12.1          
Resolution:                               |       Keywords:                  
Difficulty:                               |             Os:  Windows         
  Testcase:                               |   Architecture:  Unknown/Multiple
   Failure:  Incorrect result at runtime  |  
------------------------------------------+---------------------------------
Comment (by NeilMitchell):

 Which behaviour is right depends on how you describe the feature - either
 "it's like setting the value getArgs returns" or "it's like running it
 from the command line". It currently operates like the first, but
 operating like the second would make it more useful. I don't think the
 question of whether the shell or GHC does the expansion is that important,
 the important thing is that when run from the shell the expansion happens.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3802#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  6 14:21:27 2010
From: trac at galois.com (GHC)
Date: Wed Jan  6 13:55:49 2010
Subject: [GHC] #2965: GHC on OS X does not compile 64-bit
In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost>
References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost>
Message-ID: <054.0c3fa7dabf9e47c7377e0fd35c07c000@localhost>

#2965: GHC on OS X does not compile 64-bit
------------------------------+---------------------------------------------
  Reporter:  Axman6           |          Owner:  thoughtpolice 
      Type:  feature request  |         Status:  new           
  Priority:  normal           |      Milestone:  6.12 branch   
 Component:  Compiler         |        Version:                
Resolution:                   |       Keywords:  64bit         
Difficulty:  Unknown          |             Os:  MacOS X       
  Testcase:                   |   Architecture:  x86_64 (amd64)
   Failure:  None/Unknown     |  
------------------------------+---------------------------------------------
Changes (by filcab):

 * cc: filcab+ghc@gmail.com (added)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2965#comment:46>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  6 14:26:58 2010
From: trac at galois.com (GHC)
Date: Wed Jan  6 14:01:22 2010
Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard
In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost>
References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost>
Message-ID: <051.484c44e82611843376d809b3183c04b8@localhost>

#3400: OS X: ghc broken on Snow Leopard
---------------------------+------------------------------------------------
  Reporter:  bbb           |          Owner:  igloo  
      Type:  bug           |         Status:  closed 
  Priority:  high          |      Milestone:  6.12.1 
 Component:  Compiler      |        Version:  6.11   
Resolution:  fixed         |       Keywords:         
Difficulty:  Unknown       |             Os:  MacOS X
  Testcase:                |   Architecture:  x86    
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by filcab):

 * cc: filcab+ghc@gmail.com (added)
  * failure:  => None/Unknown

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3400#comment:19>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  6 14:28:58 2010
From: trac at galois.com (GHC)
Date: Wed Jan  6 14:02:08 2010
Subject: [GHC] #3472: Porting through .hc files broken
In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost>
References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost>
Message-ID: <055.5800b1d0310e5b7089ace15c389ba0e3@localhost>

#3472: Porting through .hc files broken
---------------------------+------------------------------------------------
  Reporter:  pumpkin       |          Owner:                  
      Type:  bug           |         Status:  new             
  Priority:  normal        |      Milestone:  6.12 branch     
 Component:  Build System  |        Version:  6.12.1 RC1      
Resolution:                |       Keywords:                  
Difficulty:  Unknown       |             Os:  Unknown/Multiple
  Testcase:                |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by filcab):

 * cc: filcab+ghc@gmail.com (added)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3472#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  6 14:41:58 2010
From: trac at galois.com (GHC)
Date: Wed Jan  6 14:14:55 2010
Subject: [GHC] #3799: undefined symbols and undefined references
 possibly related to template haskell
In-Reply-To: <049.4a0311c347285cc6754ed4f6a532bc0a@localhost>
References: <049.4a0311c347285cc6754ed4f6a532bc0a@localhost>
Message-ID: <058.88b5efa83a9a723d6438134daef79a96@localhost>

#3799: undefined symbols and undefined references possibly related to template
haskell
---------------------------------+------------------------------------------
  Reporter:  JeremyShaw          |          Owner:                                               
      Type:  bug                 |         Status:  new                                          
  Priority:  normal              |      Milestone:                                               
 Component:  Compiler            |        Version:  6.12.1                                       
Resolution:                      |       Keywords:  undefined symbols references template haskell
Difficulty:                      |             Os:  Unknown/Multiple                             
  Testcase:                      |   Architecture:  Unknown/Multiple                             
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Comment (by dsf):

 The symbol that is still undefined under GHC 6.13 is
 {{{
 happstackzmextrazm0zi76_HappstackziDataziIxSetziStore_constrZMa14JsZN_closure
 }}}
 which decodes to
 {{{
 happstack-extra-0.76_Happstack.Data.IxSet.Store_constr[a14Js]_closure
 }}}
 I will attach Store.o and Store.hi.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  6 14:50:06 2010
From: trac at galois.com (GHC)
Date: Wed Jan  6 14:23:07 2010
Subject: [GHC] #3799: undefined symbols and undefined references
 possibly related to template haskell
In-Reply-To: <049.4a0311c347285cc6754ed4f6a532bc0a@localhost>
References: <049.4a0311c347285cc6754ed4f6a532bc0a@localhost>
Message-ID: <058.38fd10110351988aa5158df95b18bd1e@localhost>

#3799: undefined symbols and undefined references possibly related to template
haskell
---------------------------------+------------------------------------------
  Reporter:  JeremyShaw          |          Owner:                                               
      Type:  bug                 |         Status:  new                                          
  Priority:  normal              |      Milestone:                                               
 Component:  Compiler            |        Version:  6.13                                         
Resolution:                      |       Keywords:  undefined symbols references template haskell
Difficulty:                      |             Os:  Unknown/Multiple                             
  Testcase:                      |   Architecture:  Unknown/Multiple                             
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Changes (by dsf):

  * version:  6.12.1 => 6.13

Comment:

 This bug is still present under ghc 6.13-20091231, though to a lesser
 extent.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  6 15:04:35 2010
From: trac at galois.com (GHC)
Date: Wed Jan  6 14:37:38 2010
Subject: [GHC] #3799: undefined symbols and undefined references
 possibly related to template haskell
In-Reply-To: <049.4a0311c347285cc6754ed4f6a532bc0a@localhost>
References: <049.4a0311c347285cc6754ed4f6a532bc0a@localhost>
Message-ID: <058.c59068faff200111e9b2e173da42cf91@localhost>

#3799: undefined symbols and undefined references possibly related to template
haskell
---------------------------------+------------------------------------------
  Reporter:  JeremyShaw          |          Owner:                                               
      Type:  bug                 |         Status:  new                                          
  Priority:  normal              |      Milestone:                                               
 Component:  Compiler            |        Version:  6.13                                         
Resolution:                      |       Keywords:  undefined symbols references template haskell
Difficulty:                      |             Os:  Unknown/Multiple                             
  Testcase:                      |   Architecture:  Unknown/Multiple                             
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Comment (by dsf):

 Compiling the package that uses this symbol with -fignore-interface-
 pragmas makes this problem go away.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  6 18:34:19 2010
From: trac at galois.com (GHC)
Date: Wed Jan  6 18:07:15 2010
Subject: [GHC] #3807: Test for correct shared library generation
Message-ID: <048.928719cb181f5e3e6b547832c856a384@localhost>

#3807: Test for correct shared library generation
---------------------------------+------------------------------------------
    Reporter:  asuffield         |       Owner:              
        Type:  bug               |      Status:  new         
    Priority:  normal            |   Component:  Test Suite  
     Version:  6.12.1            |    Keywords:              
          Os:  Unknown/Multiple  |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------
 There doesn't seem to be a test that verifies shared libraries are
 correctly created. It's not immediately obvious how to get the test suite
 driver to run this sort of thing, so I don't have a full patch for it, but
 this illustrates how it should work on ELF and ELF-like platforms:

 {{{
 asuffield@cyclone:~/work/ghc-test$ cat TestExport.hs
 module Test where
 asuffield@cyclone:~/work/ghc-test$ cat test-export.c
 #include <HsFFI.h>

 extern void __stginit_Test(void);

 void
 test_init (void)
 {
   static char *argv[] = { "test.so", 0 }, **argv_ = argv;
   static int argc = 1;

   hs_init (&argc, &argv_);
   hs_add_root (__stginit_Test);
 }

 void
 test_exit (void)
 {
   hs_exit ();
 }
 asuffield@cyclone:~/work/ghc-test$ cat testload.c
 #include <dlfcn.h>
 #include <stdio.h>

 int main(void) {
   void *dh = dlopen("./test.so", RTLD_NOW | RTLD_GLOBAL);
   if (!dh) {
     printf("%s\n", dlerror());
     return 1;
   }

   void (*test_init)(void) = dlsym(dh, "test_init");
   void (*test_exit)(void) = dlsym(dh, "test_exit");

   test_init();
   test_exit();

   return 0;
 }
 asuffield@cyclone:~/work/ghc-test$ ghc --make -dynamic -fPIC -shared
 TestExport.hs test-export.c -o test.so
 [1 of 1] Compiling Test             ( TestExport.hs, TestExport.o )
 Linking test.so ...
 asuffield@cyclone:~/work/ghc-test$ gcc -o testload testload.c -ldl
 asuffield@cyclone:~/work/ghc-test$ ./testload
 /usr/lib/ghc-6.12.0.20091126/ghc-prim-0.2.0.0/libHSghc-
 prim-0.2.0.0-ghc6.12.0.20091126.so: undefined symbol: stg_newByteArrayzh
 }}}

 You'll note that the test failed here, in a way which illustrates why the
 current FFI tests don't properly exercise this: the shared library
 references symbols from libHSrts*.so, but does not link to it. If testload
 had been compiled with ghc instead of gcc (like all the current FFI tests)
 then the binary itself would have picked up that library and caused a
 false pass; doing it this way verifies that shared libraries can be loaded
 into foreign programs. The use of dlopen here is simply to force strict
 loading of the shared library in a reasonably portable manner, since
 linking directly to it is lazily evaluated on many platforms.

 Incidentally, I suspect this will fail on current versions.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3807>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  7 02:55:55 2010
From: trac at galois.com (GHC)
Date: Thu Jan  7 02:28:49 2010
Subject: [GHC] #3353: Add CLDouble support
In-Reply-To: <044.199bb36c514cf1226e0efa905a8fa4ca@localhost>
References: <044.199bb36c514cf1226e0efa905a8fa4ca@localhost>
Message-ID: <053.32bf66a333301de1a61e7318e5b13a4e@localhost>

#3353: Add CLDouble support
---------------------------+------------------------------------------------
  Reporter:  igloo         |          Owner:                  
      Type:  bug           |         Status:  new             
  Priority:  normal        |      Milestone:  _|_             
 Component:  Compiler      |        Version:  6.12.1          
Resolution:                |       Keywords:                  
Difficulty:  Unknown       |             Os:  Unknown/Multiple
  Testcase:                |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by rtvd):

  * failure:  => None/Unknown
  * version:  6.10.2 => 6.12.1

Comment:

 CLDouble is necessary for package 'convertible', which is a dependency of
 'haskelldb-hdbc'. So, it's absence in GHC is a bit of a pain.

 I have changed the version from 6.10.2 to 6.12.1 as it is 6.12.1 that has
 this problem.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3353#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  7 04:53:57 2010
From: trac at galois.com (GHC)
Date: Thu Jan  7 04:26:56 2010
Subject: [GHC] #3808: piping  binary files sometimes fail
Message-ID: <046.03975d9a46f4033a58b89642ef5736ae@localhost>

#3808: piping  binary files sometimes fail
-------------------------------+--------------------------------------------
    Reporter:  paolino         |       Owner:                
        Type:  bug             |      Status:  new           
    Priority:  normal          |   Component:  Compiler      
     Version:  6.12.1          |    Keywords:  pipe binary IO
          Os:  Linux           |    Testcase:                
Architecture:  x86_64 (amd64)  |     Failure:  None/Unknown  
-------------------------------+--------------------------------------------
 I'm having this random bug , sometimes code succeed, sometimes not.
 It must be noted that I had to choose 5000 to exploit the randomness of it
 With 10000 it always fail, with 100 it always succeed.
 Also substituting "take 5000 fibs" with [0..5000] it always succeed,
 probably because it's much faster.


 This is the console output, for 2 consecutive shots. Notice that faster
 machines, or different kernels could need a different 5000, or never show
 the bug.


 paolino@paolino-desktop:~$ ./prod | cat |./cons
 5000
 paolino@paolino-desktop:~$ ./prod | cat |./cons
 cons: <stdin>: hLookAhead: invalid argument (Invalid or incomplete
 multibyte or wide character)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3808>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  7 07:08:44 2010
From: trac at galois.com (GHC)
Date: Thu Jan  7 06:41:40 2010
Subject: [GHC] #3808: piping  binary files sometimes fail
In-Reply-To: <046.03975d9a46f4033a58b89642ef5736ae@localhost>
References: <046.03975d9a46f4033a58b89642ef5736ae@localhost>
Message-ID: <055.038589edc867c82ba497bd9ecdb2fc71@localhost>

#3808: piping  binary files sometimes fail
-------------------------------+--------------------------------------------
    Reporter:  paolino         |       Owner:                
        Type:  bug             |      Status:  new           
    Priority:  normal          |   Milestone:                
   Component:  Compiler        |     Version:  6.12.1        
  Resolution:                  |    Keywords:  pipe binary IO
          Os:  Linux           |    Testcase:                
Architecture:  x86_64 (amd64)  |     Failure:  None/Unknown  
-------------------------------+--------------------------------------------
Changes (by Baughn):

 * cc: sveina@gmail.com (added)

Comment:

 I'd like to add that
 - If you write the output of prod to a file, and then read it in, cons
 doesn't fail.
 - If you write the output of prod to a file, and read it in through pipe
 as in 'cat output | ./cons', cons doesn't fail.
 - If you simplify prod, using [0..] instead of fibs, cons hasn't failed
 either.

 This suggests that the bug is timing-dependent, which doesn't seem
 plausible on the face of it. However, one way in which pipes are timing-
 dependent is that the read() system call can return incomplete data when
 reading from pipes (although not when reading from files, at least on
 linux). Therefore, it would be useful to consider what happens when read
 does return incomplete data.

 Regardless of the exact circumstances, the bug itself is one that should
 never happen. Reading bytestrings uses the binary hGetBuf function, and
 should always ignore encoding; thus, no encoding error should be produced.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3808#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  7 07:09:38 2010
From: trac at galois.com (GHC)
Date: Thu Jan  7 06:42:31 2010
Subject: [GHC] #3808: piping  binary files sometimes fail
In-Reply-To: <046.03975d9a46f4033a58b89642ef5736ae@localhost>
References: <046.03975d9a46f4033a58b89642ef5736ae@localhost>
Message-ID: <055.b420a7894439901dbf2236d24713f6f6@localhost>

#3808: piping  binary files sometimes fail
-------------------------------+--------------------------------------------
    Reporter:  paolino         |       Owner:                
        Type:  bug             |      Status:  new           
    Priority:  normal          |   Milestone:                
   Component:  Compiler        |     Version:  6.12.1        
  Resolution:                  |    Keywords:  pipe binary IO
          Os:  Linux           |    Testcase:                
Architecture:  x86_64 (amd64)  |     Failure:  Runtime crash 
-------------------------------+--------------------------------------------
Changes (by Baughn):

  * failure:  None/Unknown => Runtime crash

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3808#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  7 09:48:49 2010
From: trac at galois.com (GHC)
Date: Thu Jan  7 09:21:53 2010
Subject: [GHC] #3809: template-haskell 2.4 fails to compile with base 4.1
Message-ID: <049.ca9219b06862df97bec4403d1ce919ca@localhost>

#3809: template-haskell 2.4 fails to compile with base 4.1
---------------------------------+------------------------------------------
    Reporter:  benmachine        |       Owner:                   
        Type:  bug               |      Status:  new              
    Priority:  normal            |   Component:  libraries (other)
     Version:  6.10.4            |    Keywords:                   
          Os:  Unknown/Multiple  |    Testcase:                   
Architecture:  Unknown/Multiple  |     Failure:  Other            
---------------------------------+------------------------------------------
 The problem is !CharConstr, which doesn't exist in Data.Data prior to base
 4.2. I suppose the easiest fix is to update the build-depends in the cabal
 file.

 But for what it's worth I had a look and the mention of !CharConstr is so
 brief that I wonder if it's not worth factoring it out somehow in a way
 that maintains compatibility ? commenting out that single two-line case
 branch allows the build to complete fine.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3809>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  7 09:50:44 2010
From: trac at galois.com (GHC)
Date: Thu Jan  7 09:23:40 2010
Subject: [GHC] #3809: template-haskell 2.4 fails to compile with base 4.1
In-Reply-To: <049.ca9219b06862df97bec4403d1ce919ca@localhost>
References: <049.ca9219b06862df97bec4403d1ce919ca@localhost>
Message-ID: <058.d5fdbd123cdebcd17fd3380376f2b2ed@localhost>

#3809: template-haskell 2.4 fails to compile with base 4.1
----------------------------------+-----------------------------------------
    Reporter:  benmachine         |       Owner:        
        Type:  bug                |      Status:  new   
    Priority:  normal             |   Milestone:        
   Component:  libraries (other)  |     Version:  6.10.4
  Resolution:                     |    Keywords:        
          Os:  Unknown/Multiple   |    Testcase:        
Architecture:  Unknown/Multiple   |     Failure:  Other 
----------------------------------+-----------------------------------------
Changes (by benmachine):

 * cc: haskell@benmachine.co.uk (added)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3809#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  7 11:31:27 2010
From: trac at galois.com (GHC)
Date: Thu Jan  7 11:04:19 2010
Subject: [GHC] #3778: "test -e" in testsuite doesn't work with Solaris
 /bin/sh
In-Reply-To: <045.ba6d721ea8ef7ec8850eec9a0e707e83@localhost>
References: <045.ba6d721ea8ef7ec8850eec9a0e707e83@localhost>
Message-ID: <054.0f85ffe621098ec15ddf4714e262db53@localhost>

#3778: "test -e" in testsuite doesn't work with Solaris /bin/sh
--------------------------------------+-------------------------------------
  Reporter:  duncan                   |          Owner:  igloo  
      Type:  bug                      |         Status:  closed 
  Priority:  high                     |      Milestone:  6.12.2 
 Component:  Test Suite               |        Version:  6.12.1 
Resolution:  fixed                    |       Keywords:         
Difficulty:  Easy (less than 1 hour)  |             Os:  Solaris
  Testcase:                           |   Architecture:  sparc  
   Failure:  Other                    |  
--------------------------------------+-------------------------------------
Changes (by igloo):

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

Comment:

 Thanks for the report; fixed in HEAD and 6.12 by:
 {{{
 Sun Jan  3 13:11:27 GMT 2010  Ian Lynagh <igloo@earth.li>
   * Use "test -x" rather than "test -e"; fixes trac #3778
   Solaris doesn't support -e
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3778#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  7 12:26:04 2010
From: trac at galois.com (GHC)
Date: Thu Jan  7 11:58:56 2010
Subject: [GHC] #3810: Problems in core lib haddocks
Message-ID: <044.4d147541b9067d41267d81757a6f1514@localhost>

#3810: Problems in core lib haddocks
----------------------------------+-----------------------------------------
    Reporter:  igloo              |        Owner:              
        Type:  bug                |       Status:  new         
    Priority:  normal             |    Milestone:  6.12.2      
   Component:  libraries (other)  |      Version:  6.12.1      
    Keywords:                     |   Difficulty:              
          Os:  Unknown/Multiple   |     Testcase:              
Architecture:  Unknown/Multiple   |      Failure:  None/Unknown
----------------------------------+-----------------------------------------
 There are some issues with the haddock of some core libs:

 The opening "Description" in old-time's System.Time says
 {{{
 This library is deprecated, please look at Data.Time in the time package
 instead.
 }}}
 where "Data.Time" is a link, but a link to the wrong place. The easy fix
 would be to just make it no longer a link.

 The first "Source" link in the right hand column of haskell98's Array
 module is to a non-existent `GHC-Arr.html`, presumably because GHC.Arr has
 an `OPTIONS_HADDOCK hide` pragma.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3810>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  7 12:29:41 2010
From: trac at galois.com (GHC)
Date: Thu Jan  7 12:02:32 2010
Subject: [GHC] #3731: SYB gone wild - mysterious <<loop>> in code
 derived from an syb-with-class example
In-Reply-To: <042.4958fc1cdd70e26a14593e01de97e65e@localhost>
References: <042.4958fc1cdd70e26a14593e01de97e65e@localhost>
Message-ID: <051.081cc8a5413adabbfaa69c60f1140d32@localhost>

#3731: SYB gone wild - mysterious <<loop>> in code derived from an syb-with-class
example
------------------------------------------+---------------------------------
  Reporter:  dsf                          |          Owner:                  
      Type:  bug                          |         Status:  new             
  Priority:  normal                       |      Milestone:                  
 Component:  Compiler                     |        Version:  6.13            
Resolution:                               |       Keywords:                  
Difficulty:                               |             Os:  Unknown/Multiple
  Testcase:                               |   Architecture:  Unknown/Multiple
   Failure:  Incorrect result at runtime  |  
------------------------------------------+---------------------------------
Comment (by simonpj):

 Oh well that disappointing.  If you can make `Bug2` not depend on
 Happstack, that'll make it much easier for me to look at.

 But realistically, I'm pretty strongly inclined to wait for the new
 solver.  It's hard to motivate myself to look into a Very Dark Corner of
 the old solver when I'm about to throw it away entirely.

 Can you live with that?  Months, not weeks.  But not years.

 Regardless, a cut-down `Bug2` would be very very good, because I'll
 promise to use it as a test case for the new solver; so when it arrives,
 it'll solve your problem.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3731#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  7 14:15:30 2010
From: trac at galois.com (GHC)
Date: Thu Jan  7 13:48:27 2010
Subject: [GHC] #3731: SYB gone wild - mysterious <<loop>> in code
 derived from an syb-with-class example
In-Reply-To: <042.4958fc1cdd70e26a14593e01de97e65e@localhost>
References: <042.4958fc1cdd70e26a14593e01de97e65e@localhost>
Message-ID: <051.c8d9c0e60d62e21a77797288432031f4@localhost>

#3731: SYB gone wild - mysterious <<loop>> in code derived from an syb-with-class
example
------------------------------------------+---------------------------------
  Reporter:  dsf                          |          Owner:                  
      Type:  bug                          |         Status:  new             
  Priority:  normal                       |      Milestone:                  
 Component:  Compiler                     |        Version:  6.13            
Resolution:                               |       Keywords:                  
Difficulty:                               |             Os:  Unknown/Multiple
  Testcase:                               |   Architecture:  Unknown/Multiple
   Failure:  Incorrect result at runtime  |  
------------------------------------------+---------------------------------
Changes (by dsf):

 * cc: jeremy@seereason.com (added)

Comment:

 Yes, we can wait.  I have replaced Bug2.hs with a version that uses the
 attached Default.hs and NewData.hs modules instead of the modules from
 Happstack.  Perhaps Andrea Vezossi can expand out the syb-with-class stuff
 in this as he did for Bug.hs.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3731#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  8 03:56:42 2010
From: trac at galois.com (GHC)
Date: Fri Jan  8 03:30:00 2010
Subject: [GHC] #597: Various error messages have inaccurate source
 locations
In-Reply-To: <047.d9b3aa24ce12758448e171cbecc1a26d@localhost>
References: <047.d9b3aa24ce12758448e171cbecc1a26d@localhost>
Message-ID: <056.551005983cd3eb54bb6590f82cd9ae85@localhost>

#597: Various error messages have inaccurate source locations
-----------------------------------------+----------------------------------
  Reporter:  simonmar                    |          Owner:                  
      Type:  task                        |         Status:  new             
  Priority:  low                         |      Milestone:  _|_             
 Component:  Compiler                    |        Version:  None            
Resolution:  None                        |       Keywords:                  
Difficulty:  Moderate (less than a day)  |             Os:  Unknown/Multiple
  Testcase:                              |   Architecture:  Unknown/Multiple
   Failure:  Other                       |  
-----------------------------------------+----------------------------------
Comment (by simonpj):

 I believe that all are fixed now except 5, which I don't know how to do:
  * Location in LHsModule from the parser should really span the whole
 file, rather than a point span at (1,0)

 Two patches:
 {{{
 Thu Jan  7 07:11:13 PST 2010  simonpj@microsoft.com
   * A little refactoring, plus improve error locations

   Fixes some sub-items of Trac #597

     M ./compiler/typecheck/TcDeriv.lhs -2 +1
     M ./compiler/typecheck/TcInstDcls.lhs -2 +1
     M ./compiler/typecheck/TcMType.lhs -6 +17
 }}}
 and
 {{{
 Thu Jan  7 07:32:34 PST 2010  simonpj@microsoft.com
   * Improve error locations

   More on Trac #597

     M ./compiler/rename/RnBinds.lhs -21 +20
     M ./compiler/rename/RnTypes.lhs -9 +9
 }}}
 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/597#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  8 04:01:56 2010
From: trac at galois.com (GHC)
Date: Fri Jan  8 03:34:47 2010
Subject: [GHC] #3805: Bad error message "Invalid type signature"
In-Reply-To: <048.004edd9052a06de1691de17f973fb7d3@localhost>
References: <048.004edd9052a06de1691de17f973fb7d3@localhost>
Message-ID: <057.097dd2f4f5549ffcfdb4df7b77c4365b@localhost>

#3805: Bad error message "Invalid type signature"
--------------------------------+-------------------------------------------
  Reporter:  asuffield          |          Owner:                  
      Type:  bug                |         Status:  closed          
  Priority:  normal             |      Milestone:                  
 Component:  Compiler (Parser)  |        Version:  6.12.1          
Resolution:  fixed              |       Keywords:                  
Difficulty:                     |             Os:  Unknown/Multiple
  Testcase:                     |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown       |  
--------------------------------+-------------------------------------------
Changes (by simonpj):

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

Comment:

 OK I've done this, as above
 {{{
 Thu Jan  7 07:10:02 PST 2010  simonpj@microsoft.com
   * Clarify error message (Trac #3805)

     M ./compiler/parser/RdrHsSyn.lhs -1 +1
 }}}
 and
 {{{
 Tue Jan  5 09:55:32 GMT 2010  simonpj@microsoft.com
   * Improve error message (idea in Trac #3805)

   If we see

      foreign export ccall foo :: ...blah...

   we now use the "foreign" to suggest -XForeignFunctionInterface

     M ./compiler/parser/RdrHsSyn.lhs -1 +13
 }}}

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3805#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  8 04:36:26 2010
From: trac at galois.com (GHC)
Date: Fri Jan  8 04:09:15 2010
Subject: [GHC] #3811: Parse errors should display text being parsed
Message-ID: <048.46ad97689e6bccb5e95c9352fb6afccc@localhost>

#3811: Parse errors should display text being parsed
---------------------------------+------------------------------------------
    Reporter:  asuffield         |       Owner:                   
        Type:  bug               |      Status:  new              
    Priority:  normal            |   Component:  Compiler (Parser)
     Version:  6.12.1            |    Keywords:                   
          Os:  Unknown/Multiple  |    Testcase:                   
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown     
---------------------------------+------------------------------------------
 (More general form of part of #3805)

 Typical parse error:

 {{{
 TestErr.hs:1:0: Invalid type signature
 }}}

 Typical type error:

 {{{
 TestErr.hs:2:6:
     Couldn't match expected type `Int' against inferred type `[Char]'
     In the expression: "x"
     In the definition of `foo': foo = "x"
 }}}

 That explicit description of which expression was being examined is
 frequently useful in quickly understanding an error that occurs in the
 middle of a complex piece of code. There's no obvious reason why we can't
 have the same sort of thing on all parse errors - a quick glance at the
 parser suggests it's already tracking the byte range, so it should be
 fairly straightforward. I'd like to see this (on all parse errors, not
 just this one):

 {{{
 TestErr.hs:1:0:
     Invalid type signature
     While trying to parse: `foreign export ccall foo :: IO ()'
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3811>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  8 06:49:38 2010
From: trac at galois.com (GHC)
Date: Fri Jan  8 06:23:53 2010
Subject: [GHC] #650: Improve interaction between mutable arrays and GC
In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost>
References: <047.44b951cd4b5aa8536d862412c8d86597@localhost>
Message-ID: <056.ac26ced8e0cc95b07bcb6b597400e37f@localhost>

#650: Improve interaction between mutable arrays and GC
--------------------------------------+-------------------------------------
  Reporter:  simonmar                 |          Owner:  igloo           
      Type:  merge                    |         Status:  new             
  Priority:  normal                   |      Milestone:  6.12.2          
 Component:  Runtime System           |        Version:  6.4.1           
Resolution:                           |       Keywords:                  
Difficulty:  Difficult (2-5 days)     |             Os:  Unknown/Multiple
  Testcase:                           |   Architecture:  Unknown/Multiple
   Failure:  Runtime performance bug  |  
--------------------------------------+-------------------------------------
Comment (by simonmar):

 Go ahead and merge, this seems to have no adverse effects in the HEAD.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/650#comment:28>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  8 08:33:53 2010
From: trac at galois.com (GHC)
Date: Fri Jan  8 08:06:53 2010
Subject: [GHC] #3716: building ghc-6.12.0.20091121 ends with internal
 Haddock or GHC error
In-Reply-To: <045.e5c85a6d9c01c90f88c47b3f6ae70039@localhost>
References: <045.e5c85a6d9c01c90f88c47b3f6ae70039@localhost>
Message-ID: <054.0a3c3eadea9f28169b88e1b37c7ddad1@localhost>

#3716: building ghc-6.12.0.20091121 ends with internal Haddock or GHC error
----------------------------------+-----------------------------------------
  Reporter:  maeder               |          Owner:  igloo  
      Type:  bug                  |         Status:  new    
  Priority:  normal               |      Milestone:         
 Component:  Build System         |        Version:  6.12.1 
Resolution:                       |       Keywords:         
Difficulty:                       |             Os:  Solaris
  Testcase:                       |   Architecture:  x86    
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------
Changes (by igloo):

  * owner:  => igloo

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3716#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  8 16:55:25 2010
From: trac at galois.com (GHC)
Date: Fri Jan  8 16:28:18 2010
Subject: [GHC] #3292: Add an 'ignore' function to Control.Monad
In-Reply-To: <044.27c764de47060e5a6666b1886ee80198@localhost>
References: <044.27c764de47060e5a6666b1886ee80198@localhost>
Message-ID: <053.ac462389220dbf67e9044d6c637ea67e@localhost>

#3292: Add an 'ignore' function to Control.Monad
-----------------------------+----------------------------------------------
  Reporter:  guest           |          Owner:                  
      Type:  proposal        |         Status:  new             
  Priority:  normal          |      Milestone:  Not GHC         
 Component:  libraries/base  |        Version:  6.10.2          
Resolution:                  |       Keywords:                  
Difficulty:  Unknown         |             Os:  Unknown/Multiple
  Testcase:                  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown    |  
-----------------------------+----------------------------------------------
Changes (by guest):

  * failure:  => None/Unknown

Comment:

 I've attached a new patch, one using the 'void' name and Functor type
 signature.

 (I wondered about the section to put it in, but then I realized 'forever'
 wasn't in the Prelude either, so 'void' would be as happy there.)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3292#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  8 16:59:37 2010
From: trac at galois.com (GHC)
Date: Fri Jan  8 16:32:25 2010
Subject: [GHC] #3292: Add an 'ignore' function to Control.Monad
In-Reply-To: <044.27c764de47060e5a6666b1886ee80198@localhost>
References: <044.27c764de47060e5a6666b1886ee80198@localhost>
Message-ID: <053.43ae1f1b90f40e93d473cedbcb894214@localhost>

#3292: Add an 'ignore' function to Control.Monad
-----------------------------+----------------------------------------------
  Reporter:  guest           |          Owner:                  
      Type:  proposal        |         Status:  new             
  Priority:  normal          |      Milestone:  Not GHC         
 Component:  libraries/base  |        Version:  6.10.2          
Resolution:                  |       Keywords:                  
Difficulty:  Unknown         |             Os:  Unknown/Multiple
  Testcase:                  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown    |  
-----------------------------+----------------------------------------------
Comment (by guest):

 My final headcount of the very long discussion is here:
 http://www.haskell.org/pipermail/libraries/2010-January/012972.html

 I think it's clear that there's overwhelming support for adding
 void/ignore, with minor quibbling over the exact name & type signature.
 void :: f a -> f () is the best compromise, I think, and I hope now that
 Don's point about 'void' has been addressed, igloo or someone could add it
 to base.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3292#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  9 07:14:48 2010
From: trac at galois.com (GHC)
Date: Sat Jan  9 06:47:43 2010
Subject: [GHC] #3716: building ghc-6.12.0.20091121 ends with internal
 Haddock or GHC error
In-Reply-To: <045.e5c85a6d9c01c90f88c47b3f6ae70039@localhost>
References: <045.e5c85a6d9c01c90f88c47b3f6ae70039@localhost>
Message-ID: <054.682401c1b2b50e85e31367ef0dfa1ea0@localhost>

#3716: building ghc-6.12.0.20091121 ends with internal Haddock or GHC error
----------------------------------+-----------------------------------------
  Reporter:  maeder               |          Owner:  igloo  
      Type:  bug                  |         Status:  closed 
  Priority:  normal               |      Milestone:         
 Component:  Build System         |        Version:  6.12.1 
Resolution:  fixed                |       Keywords:         
Difficulty:                       |             Os:  Solaris
  Testcase:                       |   Architecture:  x86    
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------
Changes (by igloo):

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

Comment:

 Thanks; fixed in HEAD and 6.12 by
 {{{
 Fri Jan  8 13:34:16 GMT 2010  Ian Lynagh <igloo@earth.li>
   * Fix running in-place gen_contents_index; trac #3716
   It was making incorrect URLs due to a shell script error.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3716#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  9 10:10:32 2010
From: trac at galois.com (GHC)
Date: Sat Jan  9 09:44:02 2010
Subject: [GHC] #1473: isSpace is too slow
In-Reply-To: <044.3c2c0fec916372178c4bf5ce7945c8fa@abbot.galois.com>
References: <044.3c2c0fec916372178c4bf5ce7945c8fa@abbot.galois.com>
Message-ID: <053.1dd2d94bf139324c943d75e2bb1bbe67@abbot.galois.com>

#1473: isSpace is too slow
---------------------------------+------------------------------------------
    Reporter:  igloo             |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  _|_         
   Component:  libraries/base    |      Version:  6.6.1       
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by igloo):

 test

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc2/ticket/1473#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  9 17:44:59 2010
From: trac at galois.com (GHC)
Date: Sat Jan  9 17:17:44 2010
Subject: [GHC] #3812: segfault in maybePerformBlockedException
Message-ID: <045.59eb1e03b76bd0d318fceb3fb3f06570@localhost>

#3812: segfault in maybePerformBlockedException
-------------------------------+--------------------------------------------
    Reporter:  duncan          |        Owner:                     
        Type:  bug             |       Status:  new                
    Priority:  normal          |    Milestone:                     
   Component:  Runtime System  |      Version:  6.12.1             
    Keywords:                  |   Difficulty:                     
          Os:  Solaris         |     Testcase:                     
Architecture:  sparc           |      Failure:  Building GHC failed
-------------------------------+--------------------------------------------
 On the 6.12 stable branch on Sparc Solaris, the buildbot reports that
 stage2 segfaults.

 Using GDB on the core file gives us this backtrace
 {{{
 #0  0x02421dfc in maybePerformBlockedException ()
 #1  0x023fba60 in threadPaused ()
 #2  0x02412a50 in stg_returnToSched ()
 #3  0x02412a50 in stg_returnToSched ()
 }}}

 The same is not happening on the 6.13 head branch. There stage2 works ok.
 In addition the 6.12.1 release works ok.

 The `rts/RaiseAsync.c` file containing `maybePerformBlockedException` is
 currently identical between the stable and head branches.

 Sadly, relinking stage2 with -debug does not shed any light on things. We
 get a segfault with a different backtrace
 {{{
 #0  0x02399580 in integer_cmm_int2Integerzh ()
 #1  0x02397984 in sJ9_info ()
 #2  0x02397984 in sJ9_info ()
 }}}
 Of course since this is a cmm function there is no symbolic debug info.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3812>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  9 18:33:16 2010
From: trac at galois.com (GHC)
Date: Sat Jan  9 18:06:01 2010
Subject: [GHC] #3813: Invalid warning from GHCi
Message-ID: <051.207c96ece971d6767ecb4b1e779ba7b2@localhost>

#3813: Invalid warning from GHCi
---------------------------------+------------------------------------------
    Reporter:  NeilMitchell      |       Owner:                                   
        Type:  bug               |      Status:  new                              
    Priority:  normal            |   Component:  GHCi                             
     Version:  6.10.4            |    Keywords:                                   
          Os:  Unknown/Multiple  |    Testcase:                                   
Architecture:  Unknown/Multiple  |     Failure:  Incorrect warning at compile-time
---------------------------------+------------------------------------------
 {{{
 C:\Neil>ghci -Wall
 GHCi, version 6.10.3.20090530: http://www.haskell.org/ghc/  :? for help
 Loading package ghc-prim ... linking ... done.
 Loading package integer ... linking ... done.
 Loading package base ... linking ... done.
 Prelude> x <- return True

 <interactive>:1:0: Warning: Defined but not used: `x'
 Prelude> x
 True
 Prelude>
 }}}

 This error comes up in practice when writing .ghci files, for example for
 HLint. The user who reported it to me was running GHC 6.12.1.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3813>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  9 19:36:41 2010
From: trac at galois.com (GHC)
Date: Sat Jan  9 19:09:26 2010
Subject: [GHC] #3814: Compile to more than one (sub)-architecture
Message-ID: <045.81dca617e2084ce61e4f3745c003b436@localhost>

#3814: Compile to more than one (sub)-architecture
---------------------------------+------------------------------------------
    Reporter:  filcab            |       Owner:                                
        Type:  feature request   |      Status:  new                           
    Priority:  normal            |   Component:  Compiler                      
     Version:  6.12.1            |    Keywords:  architecture, compiler, x86_64
          Os:  Unknown/Multiple  |    Testcase:                                
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown                  
---------------------------------+------------------------------------------
 GHC, as far as I can tell, can only compile files for one architecture
 (let's call it the "host architecture").

 This brings some problems... The biggest of which is that we lose the
 option of building for 32/64 bits in one of the "hybrid" architectures
 (For example, in x86_64-linux or i386-darwin)

 If I build a ghc in a x86_64 linux I will only get the x86_64 code
 generator and not the i386 generator. This will stop me from building a
 program which links with a library that only has a 32-bit version.
 If I want a GHC which will only compile for the i386, I will have to
 cross-compile, which is not very pretty.

 The same will happen on the Mac OS X side (even though the x86_64-darwin
 port is still on its way...).


 But GHC "should" (IMHO) be able to do like GCC and be able to generate
 code for both architecturess (i386 and x86_64), through the usage of
 compiler flags (which would also be passed to any gcc sub-process, if need
 be). At least if it is installed in a x86_64 (and PPC, if PPC64 is
 supported) system.


 Even better would be to do like LLVM's llc which enables a user to
 generate an assembly file for a target architecture from any other
 architecture.

 Example of an LLVM target list:
 filcab@fry:/stuff/src> llc --version
 Low Level Virtual Machine (http://llvm.org/):
   llvm version 2.7svn
   DEBUG build with assertions.
   Built Jan 10 2010 (00:25:59).
   Host: x86_64-unknown-linux-gnu
   Host CPU: core2

   Registered Targets:
     arm     - ARM
     c       - C backend
     cellspu - STI CBEA Cell SPU [experimental]
     cpp     - C++ backend
     mips    - Mips
     msil    - MSIL backend
     ppc64   - PowerPC 64
     sparc   - Sparc
     x86     - 32-bit X86: Pentium-Pro and above
     x86-64  - 64-bit X86: EM64T and AMD64

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3814>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  9 19:37:00 2010
From: trac at galois.com (GHC)
Date: Sat Jan  9 19:09:45 2010
Subject: [GHC] #3814: Compile to more than one (sub)-architecture
In-Reply-To: <045.81dca617e2084ce61e4f3745c003b436@localhost>
References: <045.81dca617e2084ce61e4f3745c003b436@localhost>
Message-ID: <054.f8c47c321e5b8169104c8cd20dce56e0@localhost>

#3814: Compile to more than one (sub)-architecture
---------------------------------+------------------------------------------
    Reporter:  filcab            |       Owner:                                
        Type:  feature request   |      Status:  new                           
    Priority:  normal            |   Milestone:                                
   Component:  Compiler          |     Version:  6.12.1                        
  Resolution:                    |    Keywords:  architecture, compiler, x86_64
          Os:  Unknown/Multiple  |    Testcase:                                
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown                  
---------------------------------+------------------------------------------
Changes (by filcab):

 * cc: filcab+ghc@gmail.com (added)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3814#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 10 15:06:48 2010
From: trac at galois.com (GHC)
Date: Sun Jan 10 14:41:35 2010
Subject: [GHC] #650: Improve interaction between mutable arrays and GC
In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@abbot.galois.com>
References: <047.44b951cd4b5aa8536d862412c8d86597@abbot.galois.com>
Message-ID: <056.162ce7f39e2469ed1c5d7e8c571114c4@abbot.galois.com>

#650: Improve interaction between mutable arrays and GC
--------------------------------------+-------------------------------------
  Reporter:  simonmar                 |          Owner:  igloo           
      Type:  merge                    |         Status:  closed          
  Priority:  normal                   |      Milestone:  6.12.2          
 Component:  Runtime System           |        Version:  6.4.1           
Resolution:  fixed                    |       Keywords:                  
Difficulty:  Difficult (2-5 days)     |             Os:  Unknown/Multiple
  Testcase:                           |   Architecture:  Unknown/Multiple
   Failure:  Runtime performance bug  |  
--------------------------------------+-------------------------------------
Changes (by igloo):

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


Comment:

 Merged, along with
 {{{
 Tue Dec 22 22:20:17 GMT 2009  dias@cs.tufts.edu
   * Copying Simon M's fix for 650 to the new codegen
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/650#comment:29>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 10 17:50:08 2010
From: trac at galois.com (GHC)
Date: Sun Jan 10 17:23:36 2010
Subject: [GHC] #3801: ghc-6.10.4: internal error: PAP object entered
In-Reply-To: <047.7b8b923041b68855da236912614f1972@abbot.galois.com>
References: <047.7b8b923041b68855da236912614f1972@abbot.galois.com>
Message-ID: <056.676bba85457558e2480aee3c06b31492@abbot.galois.com>

#3801: ghc-6.10.4: internal error: PAP object entered
----------------------------+-----------------------------------------------
  Reporter:  patrikja       |          Owner:        
      Type:  bug            |         Status:  closed
  Priority:  normal         |      Milestone:        
 Component:  Compiler       |        Version:  6.10.4
Resolution:  invalid        |       Keywords:        
Difficulty:                 |             Os:  Linux 
  Testcase:                 |   Architecture:  x86   
   Failure:  Runtime crash  |  
----------------------------+-----------------------------------------------
Changes (by simonmar):

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


Comment:

 Thanks - I expect you had an inconsistent set of packages.  GHC 6.12.1 is
 better at detecting such problems.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3801#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 10 17:55:45 2010
From: trac at galois.com (GHC)
Date: Sun Jan 10 17:29:12 2010
Subject: [GHC] #3787: GHC 6.12.1 panic
In-Reply-To: <047.0ece8a101cc798eefac149b629f279fa@abbot.galois.com>
References: <047.0ece8a101cc798eefac149b629f279fa@abbot.galois.com>
Message-ID: <056.edae6ca8411f7024c613fac998dd7dd4@abbot.galois.com>

#3787: GHC 6.12.1 panic
-------------------------------+--------------------------------------------
    Reporter:  blamario        |        Owner:  simonpj           
        Type:  bug             |       Status:  new               
    Priority:  high            |    Milestone:  6.12.2            
   Component:  Compiler        |      Version:  6.12.1            
    Keywords:  panic           |   Difficulty:                    
          Os:  Linux           |     Testcase:                    
Architecture:  x86_64 (amd64)  |      Failure:  Compile-time crash
-------------------------------+--------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => simonpj


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3787#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 10 18:22:24 2010
From: trac at galois.com (GHC)
Date: Sun Jan 10 17:55:50 2010
Subject: [GHC] #3802: :main in GHCi doesn't do getArgs wildcard expansion
In-Reply-To: <051.9313883e0b6179d02dcd32988e44001c@abbot.galois.com>
References: <051.9313883e0b6179d02dcd32988e44001c@abbot.galois.com>
Message-ID: <060.04d3182abd1adecd733595a92fc4073a@abbot.galois.com>

#3802: :main in GHCi doesn't do getArgs wildcard expansion
---------------------------------+------------------------------------------
    Reporter:  NeilMitchell      |        Owner:                             
        Type:  bug               |       Status:  new                        
    Priority:  normal            |    Milestone:                             
   Component:  GHCi              |      Version:  6.12.1                     
    Keywords:                    |   Difficulty:                             
          Os:  Windows           |     Testcase:                             
Architecture:  Unknown/Multiple  |      Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------

Comment(by simonmar):

 On Windows it is true that the program does globbing, but that's because
 Windows made an astonishingly bad mistake here.  On Windows you can even
 use globbing in the arguments to `rawSystem`, but only if the program
 you're invoking supports globbing.

 Would you expect `:main <foo.txt` to work? I expect not. There's a
 slippery slope here, where we could end up implementing more and more
 shellisms in `:main` (and which shell syntax?). On the other hand, we
 already implement a little shell syntax, in that we do word-splitting and
 quoting on the arguments to `:main`.

 One interpretation of `:main` is that it is nothing but shorthand for
 `withArgs xs $ Main.main`. This interpretation I like, because it is easy
 to explain, and is platform-independent.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3802#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 10 22:57:00 2010
From: trac at galois.com (GHC)
Date: Sun Jan 10 22:30:26 2010
Subject: [GHC] #3815: System.Win32.Types.failWith segfaults on unknown error
 code
Message-ID: <049.587f27162a2b081c86f44d647b44a9da@abbot.galois.com>

#3815: System.Win32.Types.failWith segfaults on unknown error code
----------------------------------+-----------------------------------------
    Reporter:  dherington         |        Owner:                         
        Type:  bug                |       Status:  new                    
    Priority:  normal             |    Milestone:                         
   Component:  libraries (other)  |      Version:  6.10.1                 
    Keywords:  getErrorMessage    |   Difficulty:  Easy (less than 1 hour)
          Os:  Windows            |     Testcase:                         
Architecture:  Unknown/Multiple   |      Failure:  Runtime crash          
----------------------------------+-----------------------------------------
 If a (Windows) system call returns an error code not known to
 FormatMessage, System.Win32.Types.failWith segfaults.  failWith
 incorrectly assumes that getErrorMessage never returns a NULL pointer.

 A simple fix in failWith is to replace:

   msg <- peekTString c_msg
   -- We ignore failure of freeing c_msg, given we're already failing
   _ <- localFree c_msg

 by:

   msg <- if c_msg == nullPtr
            then return $ "Error 0x" ++ Numeric.showHex err_code ""
            else do msg <- peekTString c_msg
                    -- We ignore failure of freeing c_msg, given we're
 already failing
                    _ <- localFree c_msg
                    return msg

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3815>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 11 03:20:14 2010
From: trac at galois.com (GHC)
Date: Mon Jan 11 02:53:42 2010
Subject: [GHC] #3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's
 value when specified C compiler to use
In-Reply-To: <042.c4b5030684625e3b4acbf7f52bd1fe70@abbot.galois.com>
References: <042.c4b5030684625e3b4acbf7f52bd1fe70@abbot.galois.com>
Message-ID: <051.9f76350d34d42175bf294dee7d9ac617@abbot.galois.com>

#3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C
compiler to use
------------------------+---------------------------------------------------
    Reporter:  nwn      |        Owner:            
        Type:  bug      |       Status:  new       
    Priority:  normal   |    Milestone:  6.14.1    
   Component:  hsc2hs   |      Version:  6.12.1 RC1
    Keywords:           |   Difficulty:            
          Os:  MacOS X  |     Testcase:            
Architecture:  x86      |      Failure:  Other     
------------------------+---------------------------------------------------
Changes (by bos):

 * cc: bos@? (added)


Comment:

 So this will be fixed in 6.12.2, is that correct?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3681#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From marlowsd at gmail.com  Mon Jan 11 11:51:38 2010
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon Jan 11 11:24:23 2010
Subject: [GHC] #650: Improve interaction between mutable arrays and GC
In-Reply-To: <056.162ce7f39e2469ed1c5d7e8c571114c4@abbot.galois.com>
References: <047.44b951cd4b5aa8536d862412c8d86597@abbot.galois.com>
	<056.162ce7f39e2469ed1c5d7e8c571114c4@abbot.galois.com>
Message-ID: <4B4B571A.4070602@gmail.com>

Switching to the new server has messed up threading for ghc-bugs emails. 
  I think the culprit is this:

References: <047.44b951cd4b5aa8536d862412c8d86597@abbot.galois.com>
In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@abbot.galois.com>

these references point to @abbot.galois.com, rather than 
@monk.galois.com. It's not a showstopper, but it's somewhat annoying.
Can anything be done about it?

Cheers,
	Simon
From trac at galois.com  Mon Jan 11 11:55:05 2010
From: trac at galois.com (GHC)
Date: Mon Jan 11 11:28:32 2010
Subject: [GHC] #3815: System.Win32.Types.failWith segfaults on unknown
 error code
In-Reply-To: <049.587f27162a2b081c86f44d647b44a9da@abbot.galois.com>
References: <049.587f27162a2b081c86f44d647b44a9da@abbot.galois.com>
Message-ID: <058.e736e1fc3db3e48d2f9f5bcd636e3c5b@abbot.galois.com>

#3815: System.Win32.Types.failWith segfaults on unknown error code
----------------------------------+-----------------------------------------
    Reporter:  dherington         |        Owner:                         
        Type:  bug                |       Status:  new                    
    Priority:  high               |    Milestone:  6.12.2                 
   Component:  libraries (other)  |      Version:  6.10.1                 
    Keywords:  getErrorMessage    |   Difficulty:  Easy (less than 1 hour)
          Os:  Windows            |     Testcase:                         
Architecture:  Unknown/Multiple   |      Failure:  Runtime crash          
----------------------------------+-----------------------------------------
Changes (by simonmar):

  * priority:  normal => high
  * milestone:  => 6.12.2


Old description:

> If a (Windows) system call returns an error code not known to
> FormatMessage, System.Win32.Types.failWith segfaults.  failWith
> incorrectly assumes that getErrorMessage never returns a NULL pointer.
>
> A simple fix in failWith is to replace:
>
>   msg <- peekTString c_msg
>   -- We ignore failure of freeing c_msg, given we're already failing
>   _ <- localFree c_msg
>
> by:
>
>   msg <- if c_msg == nullPtr
>            then return $ "Error 0x" ++ Numeric.showHex err_code ""
>            else do msg <- peekTString c_msg
>                    -- We ignore failure of freeing c_msg, given we're
> already failing
>                    _ <- localFree c_msg
>                    return msg

New description:

 If a (Windows) system call returns an error code not known to
 FormatMessage, System.Win32.Types.failWith segfaults.  failWith
 incorrectly assumes that getErrorMessage never returns a NULL pointer.

 A simple fix in failWith is to replace:

 {{{
   msg <- peekTString c_msg
   -- We ignore failure of freeing c_msg, given we're already failing
   _ <- localFree c_msg
 }}}

 by:

 {{{
   msg <- if c_msg == nullPtr
            then return $ "Error 0x" ++ Numeric.showHex err_code ""
            else do msg <- peekTString c_msg
                    -- We ignore failure of freeing c_msg, given we're
 already failing
                    _ <- localFree c_msg
                    return msg
 }}}

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3815#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 11 14:56:17 2010
From: trac at galois.com (GHC)
Date: Mon Jan 11 14:29:47 2010
Subject: [GHC] #3808: piping  binary files sometimes fail
In-Reply-To: <046.03975d9a46f4033a58b89642ef5736ae@abbot.galois.com>
References: <046.03975d9a46f4033a58b89642ef5736ae@abbot.galois.com>
Message-ID: <055.fde3505b8e221ab51f836a5f76315db4@abbot.galois.com>

#3808: piping  binary files sometimes fail
-------------------------------+--------------------------------------------
    Reporter:  paolino         |        Owner:  simonmar     
        Type:  bug             |       Status:  assigned     
    Priority:  high            |    Milestone:  6.12.2       
   Component:  Compiler        |      Version:  6.12.1       
    Keywords:  pipe binary IO  |   Difficulty:               
          Os:  Linux           |     Testcase:               
Architecture:  x86_64 (amd64)  |      Failure:  Runtime crash
-------------------------------+--------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar
  * priority:  normal => high
  * status:  new => assigned
  * milestone:  => 6.12.2


Comment:

 `Data.ByteString.Lazy.hGetContents` calls `hIsEOF` which calls
 `hLookAhead`, and `hLookAhead` reads the next `Char` from the `Handle`,
 which does Unicode decoding. Putting `stdin` into binary mode fixes the
 problem.

 After giving this a bit of thought, I think the best solution is to make
 `hIsEOF` not do any decoding, so I'll look into doing that.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3808#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 11 15:09:45 2010
From: trac at galois.com (GHC)
Date: Mon Jan 11 14:43:18 2010
Subject: [GHC] #3812: segfault in maybePerformBlockedException
In-Reply-To: <045.59eb1e03b76bd0d318fceb3fb3f06570@abbot.galois.com>
References: <045.59eb1e03b76bd0d318fceb3fb3f06570@abbot.galois.com>
Message-ID: <054.762d95cd35e5c76ab7c84c3fc188d0de@abbot.galois.com>

#3812: segfault in maybePerformBlockedException
-------------------------------+--------------------------------------------
    Reporter:  duncan          |        Owner:                     
        Type:  bug             |       Status:  new                
    Priority:  normal          |    Milestone:  6.12.2             
   Component:  Runtime System  |      Version:  6.12.1             
    Keywords:                  |   Difficulty:                     
          Os:  Solaris         |     Testcase:                     
Architecture:  sparc           |      Failure:  Building GHC failed
-------------------------------+--------------------------------------------
Changes (by simonmar):

  * milestone:  => 6.12.2


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3812#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 11 15:24:40 2010
From: trac at galois.com (GHC)
Date: Mon Jan 11 14:58:06 2010
Subject: [GHC] #3808: piping  binary files sometimes fail
In-Reply-To: <046.03975d9a46f4033a58b89642ef5736ae@abbot.galois.com>
References: <046.03975d9a46f4033a58b89642ef5736ae@abbot.galois.com>
Message-ID: <055.f149fbafad72aa979482c45e4aca5021@abbot.galois.com>

#3808: piping  binary files sometimes fail
-------------------------------+--------------------------------------------
    Reporter:  paolino         |        Owner:  simonmar     
        Type:  bug             |       Status:  assigned     
    Priority:  high            |    Milestone:  6.12.2       
   Component:  Compiler        |      Version:  6.12.1       
    Keywords:  pipe binary IO  |   Difficulty:               
          Os:  Linux           |     Testcase:               
Architecture:  x86_64 (amd64)  |      Failure:  Runtime crash
-------------------------------+--------------------------------------------
Changes (by simonmar):

 * cc: dons@? (added)


Comment:

 It's not so easy.  Bytestring also calls `hWaitForInput`, which does
 decoding because it only returns when there is at least one full character
 to read, not a partial byte sequence.  This is the only sensible semantics
 for `hWaitForInput`, so I'm afraid we have to take a different approach: I
 suggest ByteString stops using `hWaitForInput` (I can fix `hIsEOF` as
 described above).

 I looked at the code for `DB.Lazy.hGetContents`, and as far as I can tell
 it should be possible to use a blocking read rather than the
 `hGetNonBlocking`, `hIsEOF`, `hWaitForInput` combination that is used now.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3808#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 11 17:07:55 2010
From: trac at galois.com (GHC)
Date: Mon Jan 11 16:41:23 2010
Subject: [GHC] #3816: System.Posix.GetAllGroupEntries returns 0 groups for
 2nd and subsequent calls
Message-ID: <047.6ed51ca280e5f40fc20f0caf56b9b6f6@abbot.galois.com>

#3816: System.Posix.GetAllGroupEntries returns 0 groups for 2nd and subsequent
calls
------------------------------------------------+---------------------------
    Reporter:  tphyahoo                         |        Owner:                
        Type:  bug                              |       Status:  new           
    Priority:  normal                           |    Milestone:                
   Component:  Compiler                         |      Version:  6.10.4        
    Keywords:  groups getAllGroupentries posix  |   Difficulty:  Unknown       
          Os:  Linux                            |     Testcase:  in description
Architecture:  x86_64 (amd64)                   |      Failure:  None/Unknown  
------------------------------------------------+---------------------------
 This is on 6.10.4, could someone check whether still a bug on 6.12?

  #haskell Jan 11 2010:

 <patch-tag> liftM length System.Posix.getAllGroupEntries

 <patch-tag> 1819

 <patch-tag> Prelude System.Posix Control.Monad> liftM length

 <patch-tag> 0

  lispy/cale confirmed behavior, and cale suggested fix:

  <lispy> patch-tag:
 http://www.haskell.org/ghc/docs/6.10.4/html/libraries/unix/src/System-
 Posix-User.html#getAllGroupEntries


 <Cale> getAllUserEntries =

 <Cale>     withMVar lock $ \_ -> bracket_ c_setpwent c_endpwent $ worker
 []

 <Cale> getAllUserEntries is properly bracketed

 <Cale> getAllGroupEntries = withMVar lock $ \_ -> worker []

 <lispy> http://linux.about.com/library/cmd/blcmdl3_getgrent.htm

 function has changed from 6.10.4 to 6.12 but I'm not sure if this fixed
 the bug:
  6.10.4: http://www.haskell.org/ghc/docs/6.10.4/html/libraries/unix/src
 /System-Posix-User.html#getAllGroupEntries
  6.12:
 http://hackage.haskell.org/packages/archive/unix/2.4.0.0/doc/html/src
 /System-Posix-User.html

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3816>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 12 11:51:05 2010
From: trac at galois.com (GHC)
Date: Tue Jan 12 11:48:04 2010
Subject: [GHC] #3817: -fvia-C / mangler fails with gcc-4.3.x on sparc;
 suggest disabling -fvia-C
Message-ID: <045.763dbbac5925c7bf65ed54ed1092e47b@abbot.galois.com>

#3817: -fvia-C / mangler fails with gcc-4.3.x on sparc; suggest disabling -fvia-C
---------------------------------+------------------------------------------
    Reporter:  duncan            |        Owner:                         
        Type:  bug               |       Status:  new                    
    Priority:  low               |    Milestone:                         
   Component:  Driver            |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:  Easy (less than 1 hour)
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  sparc             |      Failure:  Runtime crash          
---------------------------------+------------------------------------------
 The Evil Mangler does not grok the output of gcc-4.3.x on Sparc systems
 (Linux or Solaris). Results look like:

 {{{
 [1 of 1] Compiling Main             ( Main.hs, Main.o )
 /tmp/ghc19196_0/ghc19196_0.hc: In function ?rhT_entry?:

 /tmp/ghc19196_0/ghc19196_0.hc:38:0:
      note: if this code is reached, the program will abort
 }}}
 And that which it prophesies does come to pass
 {{{
 $ ./Main
 Illegal instruction
 }}}

 I don't suggest anyone actually fix the Evil Mangler. Instead we could
 just disable -fvia-C (registerised). Have sparc be the first arch to make
 the switch! Alternatively, if we're feeling generous, only enable support
 for registerised -fvia-C if ./configure detects gcc version 4.2 or less.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3817>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 12 16:56:14 2010
From: trac at galois.com (GHC)
Date: Tue Jan 12 16:29:40 2010
Subject: [GHC] #3292: Add an 'ignore' function to Control.Monad
In-Reply-To: <044.27c764de47060e5a6666b1886ee80198@abbot.galois.com>
References: <044.27c764de47060e5a6666b1886ee80198@abbot.galois.com>
Message-ID: <053.2601c9511dd210a5ef7016c2b7e4cfbc@abbot.galois.com>

#3292: Add an 'ignore' function to Control.Monad
---------------------------------+------------------------------------------
    Reporter:  guest             |        Owner:              
        Type:  proposal          |       Status:  new         
    Priority:  normal            |    Milestone:  Not GHC     
   Component:  libraries/base    |      Version:  6.10.2      
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by guest):

 What needs to be done to get this applied? Since the patch/email/ticket
 flurry 4 days, there haven't even been any objections. Is there someone I
 need to specifically email or chat with in #haskell?

 --gwern

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3292#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 12 17:22:34 2010
From: trac at galois.com (GHC)
Date: Tue Jan 12 16:56:09 2010
Subject: [GHC] #3292: Add an 'ignore' function to Control.Monad
In-Reply-To: <044.27c764de47060e5a6666b1886ee80198@abbot.galois.com>
References: <044.27c764de47060e5a6666b1886ee80198@abbot.galois.com>
Message-ID: <053.8c36bce193f69ca784616f17ea812d67@abbot.galois.com>

#3292: Add an 'ignore' function to Control.Monad
---------------------------------+------------------------------------------
    Reporter:  guest             |        Owner:              
        Type:  merge             |       Status:  new         
    Priority:  normal            |    Milestone:  Not GHC     
   Component:  libraries/base    |      Version:  6.12.1      
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by malcolm.wallace@?):

  * version:  6.10.2 => 6.12.1
  * type:  proposal => merge


Comment:

 Patch applied.  Should it be merged to the ghc-6.12.x branch?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3292#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 12 18:16:21 2010
From: trac at galois.com (GHC)
Date: Tue Jan 12 17:49:54 2010
Subject: [GHC] #3292: Add an 'ignore' function to Control.Monad
In-Reply-To: <044.27c764de47060e5a6666b1886ee80198@abbot.galois.com>
References: <044.27c764de47060e5a6666b1886ee80198@abbot.galois.com>
Message-ID: <053.eaa002948ad7caec9763ee2b8ca775f6@abbot.galois.com>

#3292: Add an 'ignore' function to Control.Monad
---------------------------------+------------------------------------------
    Reporter:  guest             |        Owner:              
        Type:  merge             |       Status:  new         
    Priority:  normal            |    Milestone:  Not GHC     
   Component:  libraries/base    |      Version:  6.12.1      
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by guest):

 Malcolm: I don't see any reason why it shouldn't be, do you?

 (I suppose this would involve issues of base's version-number, but I don't
 know anything about that.)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3292#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 12 18:31:52 2010
From: trac at galois.com (GHC)
Date: Tue Jan 12 18:05:27 2010
Subject: [GHC] #3292: Add an 'ignore' function to Control.Monad
In-Reply-To: <044.27c764de47060e5a6666b1886ee80198@abbot.galois.com>
References: <044.27c764de47060e5a6666b1886ee80198@abbot.galois.com>
Message-ID: <053.692cf9035f42e9b80dd173668cbc96d7@abbot.galois.com>

#3292: Add an 'ignore' function to Control.Monad
-----------------------------+----------------------------------------------
  Reporter:  guest           |          Owner:                  
      Type:  proposal        |         Status:  closed          
  Priority:  normal          |      Milestone:  Not GHC         
 Component:  libraries/base  |        Version:  6.13            
Resolution:  fixed           |       Keywords:                  
Difficulty:  Unknown         |             Os:  Unknown/Multiple
  Testcase:                  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown    |  
-----------------------------+----------------------------------------------
Changes (by ross):

  * status:  new => closed
  * type:  merge => proposal
  * version:  6.12.1 => 6.13
  * resolution:  => fixed


Comment:

 We don't change the API of core packages during the cycle.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3292#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 06:38:55 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 06:12:22 2010
Subject: [GHC] #3780: unix-2.4.0.0 fails with base 4.1
In-Reply-To: <045.da767e73d04d85283e231ed41de5ef94@abbot.galois.com>
References: <045.da767e73d04d85283e231ed41de5ef94@abbot.galois.com>
Message-ID: <054.863420b73cf66b44239e19e81548070d@abbot.galois.com>

#3780: unix-2.4.0.0 fails with base 4.1
---------------------------------+------------------------------------------
    Reporter:  duncan            |        Owner:                         
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  6.12.2                 
   Component:  libraries/unix    |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:  Easy (less than 1 hour)
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Other                  
---------------------------------+------------------------------------------
Changes (by simonmar):

  * milestone:  => 6.12.2


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3780#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 08:07:35 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 07:41:00 2010
Subject: [GHC] #3647: unify handling and error messages for -X vs.
 {-#LANGUAGE ...#-} pragmas/extensions
In-Reply-To: <047.73fc8cca3ba98859dc9d57483a25d637@abbot.galois.com>
References: <047.73fc8cca3ba98859dc9d57483a25d637@abbot.galois.com>
Message-ID: <056.fd1822db9b692a41bd6b6b849c25c24a@abbot.galois.com>

#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
--------------------------------+-------------------------------------------
  Reporter:  eflister           |          Owner:                                                  
      Type:  feature request    |         Status:  closed                                          
  Priority:  normal             |      Milestone:                                                  
 Component:  Compiler (Parser)  |        Version:  6.10.4                                          
Resolution:  wontfix            |       Keywords:  language pragma extensions error message warning
Difficulty:                     |             Os:  Unknown/Multiple                                
  Testcase:                     |   Architecture:  Unknown/Multiple                                
   Failure:  None/Unknown       |  
--------------------------------+-------------------------------------------
Changes (by igloo):

  * status:  new => closed
  * failure:  => None/Unknown
  * resolution:  => wontfix


Comment:

 I agree with Duncan: If GHC accepted
 {{{
 {-# LANGUAGE -XFoo #-}
 }}}
 then people would start using it, and then the code would not be portable.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3647#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 08:13:17 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 07:46:45 2010
Subject: [GHC] #3680: Improve docs for 'length'
In-Reply-To: <056.32b26bd2c9b5e88047fb0bedd9442617@abbot.galois.com>
References: <056.32b26bd2c9b5e88047fb0bedd9442617@abbot.galois.com>
Message-ID: <065.1b000b389dc5241da6dffd658517ada7@abbot.galois.com>

#3680: Improve docs for 'length'
----------------------------------+-----------------------------------------
    Reporter:  daniel.is.fischer  |        Owner:                   
        Type:  feature request    |       Status:  new              
    Priority:  normal             |    Milestone:  6.12.2           
   Component:  libraries/base     |      Version:  6.10.4           
    Keywords:                     |   Difficulty:                   
          Os:  Unknown/Multiple   |     Testcase:                   
Architecture:  Unknown/Multiple   |      Failure:  Documentation bug
----------------------------------+-----------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3680#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 08:14:37 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 07:48:03 2010
Subject: [GHC] #3686: please remove huge ghc-tarballs/
In-Reply-To: <050.b4bccaf6c9a8808a0840e4e3f64c6887@abbot.galois.com>
References: <050.b4bccaf6c9a8808a0840e4e3f64c6887@abbot.galois.com>
Message-ID: <059.7a6d11c47a9d4e43d60601570424ed33@abbot.galois.com>

#3686: please remove huge ghc-tarballs/
---------------------------+------------------------------------------------
  Reporter:  juhpetersen   |          Owner:                  
      Type:  bug           |         Status:  closed          
  Priority:  normal        |      Milestone:                  
 Component:  Build System  |        Version:  6.12.1 RC1      
Resolution:  wontfix       |       Keywords:                  
Difficulty:                |             Os:  Unknown/Multiple
  Testcase:                |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by igloo):

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


Comment:

 Personally I am inclined to keep it simple, so in the absence of other
 opinions I'll close this ticket.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3686#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 08:17:56 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 07:51:22 2010
Subject: [GHC] #3687: Merge _stub.o files back in to the .o file
In-Reply-To: <051.5329623a4eddfae039053b6416bd32a2@abbot.galois.com>
References: <051.5329623a4eddfae039053b6416bd32a2@abbot.galois.com>
Message-ID: <060.b420f49d7ed45949cb9119c610ca2837@abbot.galois.com>

#3687: Merge _stub.o files back in to the .o file
---------------------------------+------------------------------------------
    Reporter:  NeilMitchell      |        Owner:              
        Type:  feature request   |       Status:  new         
    Priority:  normal            |    Milestone:  6.12 branch 
   Component:  Compiler          |      Version:  6.10.4      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12 branch


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3687#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 08:35:46 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 08:09:13 2010
Subject: [GHC] #3691: Error message doesn't mention necessary extension
 in warning
In-Reply-To: <045.4e6de20074a753fbe79a2f142c50f383@abbot.galois.com>
References: <045.4e6de20074a753fbe79a2f142c50f383@abbot.galois.com>
Message-ID: <054.9cc94946f9d935e37d455f9cbfe44f17@abbot.galois.com>

#3691: Error message doesn't mention necessary extension in warning
------------------------------------------------+---------------------------
  Reporter:  arsenm                             |          Owner:                  
      Type:  feature request                    |         Status:  closed          
  Priority:  normal                             |      Milestone:                  
 Component:  Compiler                           |        Version:  6.10.4          
Resolution:  duplicate                          |       Keywords:                  
Difficulty:                                     |             Os:  Unknown/Multiple
  Testcase:                                     |   Architecture:  Unknown/Multiple
   Failure:  Incorrect warning at compile-time  |  
------------------------------------------------+---------------------------
Changes (by igloo):

  * status:  reopened => closed
  * resolution:  => duplicate


Comment:

 If I've followed correctly, this ticket has morphed into a duplicate of
 #1316.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3691#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 08:35:57 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 08:09:23 2010
Subject: [GHC] #1316: add warning for local type signatures that use the
 same type variable names as outer type signatures
In-Reply-To: <051.fc0097e380c9c982131869ff2c172623@abbot.galois.com>
References: <051.fc0097e380c9c982131869ff2c172623@abbot.galois.com>
Message-ID: <060.5b9da1c905bf89e16d7842a299dbd94b@abbot.galois.com>

#1316: add warning for local type signatures that use the same type variable names
as outer type signatures
---------------------------------+------------------------------------------
    Reporter:  Isaac Dupree      |        Owner:  simonpj     
        Type:  feature request   |       Status:  new         
    Priority:  normal            |    Milestone:  _|_         
   Component:  Compiler          |      Version:  6.6.1       
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * failure:  => None/Unknown


Comment:

 See also #3691.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1316#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 08:51:23 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 08:24:48 2010
Subject: [GHC] #3692: TcTyFuns.flattenType: unexpected PredType
In-Reply-To: <043.b692713f9a8cc70230a5cc7f658ed0bf@abbot.galois.com>
References: <043.b692713f9a8cc70230a5cc7f658ed0bf@abbot.galois.com>
Message-ID: <052.d335fdd8174a61e80ed56962942aa6e1@abbot.galois.com>

#3692: TcTyFuns.flattenType: unexpected PredType
---------------------------------+------------------------------------------
  Reporter:  cdfh                |          Owner:                         
      Type:  bug                 |         Status:  closed                 
  Priority:  normal              |      Milestone:                         
 Component:  Compiler            |        Version:  6.10.4                 
Resolution:  fixed               |       Keywords:  TcTyFuns PredType panic
Difficulty:                      |             Os:  Linux                  
  Testcase:                      |   Architecture:  x86_64 (amd64)         
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Changes (by igloo):

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


Comment:

 Thanks for the report. I can reproduce this in 6.10.4, but HEAD and 6.12
 say:
 {{{
 vi.hs:6:10:
     Could not deduce (Bar ((Bar a) => a)) from the context ()
       arising from an expression type signature at vi.hs:6:10-29
     Possible fix:
       add (Bar ((Bar a) => a)) to the context of
         the type signature for `foo'
       or add an instance declaration for (Bar ((Bar a) => a))
     In the first argument of `id', namely `(undefined :: Foo a b)'
     In the expression: id (undefined :: Foo a b)
     In the definition of `foo': foo = id (undefined :: Foo a b)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3692#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 08:56:09 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 08:29:38 2010
Subject: [GHC] #3696: Incorrect type inferred with
 -fwarn-missing-signatures and a type class
In-Reply-To: <042.114a9e9c46098b4fa4159f581cedcf51@abbot.galois.com>
References: <042.114a9e9c46098b4fa4159f581cedcf51@abbot.galois.com>
Message-ID: <051.d90772244871de8f9a85cc0fe304733c@abbot.galois.com>

#3696: Incorrect type inferred with -fwarn-missing-signatures and a type class
----------------------------------------+-----------------------------------
    Reporter:  spl                      |        Owner:                                   
        Type:  bug                      |       Status:  new                              
    Priority:  normal                   |    Milestone:  6.12.2                           
   Component:  Compiler (Type checker)  |      Version:  6.10.1                           
    Keywords:                           |   Difficulty:                                   
          Os:  Unknown/Multiple         |     Testcase:                                   
Architecture:  Unknown/Multiple         |      Failure:  Incorrect warning at compile-time
----------------------------------------+-----------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


Comment:

 This also happens in HEAD and 6.12.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3696#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 08:56:38 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 08:30:03 2010
Subject: [GHC] #3697: Method selectors aren't floated out of loops
In-Reply-To: <041.f5e0d472d08f4dccb3e0fe41dd7a6eba@abbot.galois.com>
References: <041.f5e0d472d08f4dccb3e0fe41dd7a6eba@abbot.galois.com>
Message-ID: <050.62f93bd0edcd9c9ad4a2f4858fe0b81a@abbot.galois.com>

#3697: Method selectors aren't floated out of loops
---------------------------------+------------------------------------------
    Reporter:  rl                |        Owner:                         
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  6.14 branch            
   Component:  Compiler          |      Version:  6.13                   
    Keywords:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.14 branch


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3697#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 08:57:04 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 08:30:29 2010
Subject: [GHC] #3698: Bad code generated for zip/filter/filter loop
In-Reply-To: <041.1bc18587ecffea6f67a927d7ce3ba4be@abbot.galois.com>
References: <041.1bc18587ecffea6f67a927d7ce3ba4be@abbot.galois.com>
Message-ID: <050.4de66950fff2e8a53e116c852ee364fd@abbot.galois.com>

#3698: Bad code generated for zip/filter/filter loop
---------------------------------+------------------------------------------
    Reporter:  rl                |        Owner:                         
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  6.14 branch            
   Component:  Compiler          |      Version:  6.13                   
    Keywords:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.14 branch


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3698#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 09:03:09 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 08:36:34 2010
Subject: [GHC] #3701: allow existential wrapper newtypes
In-Reply-To: <045.840f456f2d890bcf682319446631153e@abbot.galois.com>
References: <045.840f456f2d890bcf682319446631153e@abbot.galois.com>
Message-ID: <054.d16bec9770f80e1ed36d5fb08db7edea@abbot.galois.com>

#3701: allow existential wrapper newtypes
---------------------------------+------------------------------------------
    Reporter:  duncan            |        Owner:              
        Type:  feature request   |       Status:  new         
    Priority:  normal            |    Milestone:  6.14 branch 
   Component:  Compiler          |      Version:  6.10.4      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.14 branch


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3701#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 09:04:58 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 08:38:24 2010
Subject: [GHC] #3704: Using -shared without -dynamic should be rejected
 on linux
In-Reply-To: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@abbot.galois.com>
References: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@abbot.galois.com>
Message-ID: <057.1f438e457aa770311afa2e6a6757e10e@abbot.galois.com>

#3704: Using -shared without -dynamic should be rejected on linux
---------------------------------+------------------------------------------
    Reporter:  asuffield         |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  6.14.1      
   Component:  Compiler          |      Version:              
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.14.1


Comment:

 Is there a conclusion as to what should be done for this ticket?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3704#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 09:49:35 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 09:23:02 2010
Subject: [GHC] #3711: Bad error reporting when calling a function in a
 module which depends on a DLL on Windows
In-Reply-To: <044.70cf7493cde2b6d5c034e6655b6cb8a7@abbot.galois.com>
References: <044.70cf7493cde2b6d5c034e6655b6cb8a7@abbot.galois.com>
Message-ID: <053.80cd2354ad0f1874de1fafdbb08e9bc5@abbot.galois.com>

#3711: Bad error reporting when calling a function in a module which depends on a
DLL on Windows
---------------------------+------------------------------------------------
  Reporter:  fasta         |           Type:  bug             
    Status:  new           |       Priority:  normal          
 Milestone:  6.12.2        |      Component:  Runtime System  
   Version:  6.10.4        |       Keywords:                  
Difficulty:                |             Os:  Windows         
  Testcase:                |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3711#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 09:59:57 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 09:33:24 2010
Subject: [GHC] #3647: unify handling and error messages for -X vs.
 {-#LANGUAGE ...#-} pragmas/extensions
In-Reply-To: <047.73fc8cca3ba98859dc9d57483a25d637@abbot.galois.com>
References: <047.73fc8cca3ba98859dc9d57483a25d637@abbot.galois.com>
Message-ID: <056.d050a330248545cc0428e67fa24329f2@abbot.galois.com>

#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
--------------------------------+-------------------------------------------
  Reporter:  eflister           |          Owner:                                                  
      Type:  feature request    |         Status:  reopened                                        
  Priority:  normal             |      Milestone:                                                  
 Component:  Compiler (Parser)  |        Version:  6.10.4                                          
Resolution:                     |       Keywords:  language pragma extensions error message warning
Difficulty:                     |             Os:  Unknown/Multiple                                
  Testcase:                     |   Architecture:  Unknown/Multiple                                
   Failure:  None/Unknown       |  
--------------------------------+-------------------------------------------
Changes (by eflister):

  * status:  closed => reopened
  * resolution:  wontfix =>


Comment:

 Replying to [comment:4 igloo]:

 you could still fix the error message.  from OP:

 the ghc error message indicating that an extension should be added should
 print out a message that would make for easy cut and paste without
 modification into *either* one's language pragma or command line -X
 extension args.

 what about accepting -Extension flags (without the X) at the command line?
 how is that X helping anyone?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3647#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 11:39:22 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 11:12:49 2010
Subject: [GHC] #3692: Bogus type error message in type with constraints
 after the arrow (was: TcTyFuns.flattenType: unexpected PredType)
In-Reply-To: <043.b692713f9a8cc70230a5cc7f658ed0bf@abbot.galois.com>
References: <043.b692713f9a8cc70230a5cc7f658ed0bf@abbot.galois.com>
Message-ID: <052.0eee5d081da3163a4f7187738caac316@abbot.galois.com>

#3692: Bogus type error message in type with constraints after the arrow
---------------------------------+------------------------------------------
  Reporter:  cdfh                |          Owner:                         
      Type:  bug                 |         Status:  reopened               
  Priority:  normal              |      Milestone:  6.14 branch            
 Component:  Compiler            |        Version:  6.12.1                 
Resolution:                      |       Keywords:  TcTyFuns PredType panic
Difficulty:                      |             Os:  Linux                  
  Testcase:                      |   Architecture:  x86_64 (amd64)         
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Changes (by simonpj):

  * status:  closed => reopened
  * resolution:  fixed =>
  * version:  6.10.4 => 6.12.1
  * milestone:  => 6.14 branch


Comment:

 The error message is totally bogus.  I'll fix this in my constraint-
 solving sweep.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3692#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 15:32:47 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 15:06:16 2010
Subject: [GHC] #3731: SYB gone wild - mysterious <<loop>> in code
 derived from an syb-with-class example
In-Reply-To: <042.4958fc1cdd70e26a14593e01de97e65e@abbot.galois.com>
References: <042.4958fc1cdd70e26a14593e01de97e65e@abbot.galois.com>
Message-ID: <051.8f319cdbf31627998c0547f84b92b5b2@abbot.galois.com>

#3731: SYB gone wild - mysterious <<loop>> in code derived from an syb-with-class
example
---------------------------------+------------------------------------------
    Reporter:  dsf               |        Owner:                             
        Type:  bug               |       Status:  new                        
    Priority:  normal            |    Milestone:  6.14.1                     
   Component:  Compiler          |      Version:  6.13                       
    Keywords:                    |   Difficulty:                             
          Os:  Unknown/Multiple  |     Testcase:                             
Architecture:  Unknown/Multiple  |      Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.14.1


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3731#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 15:33:05 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 15:06:32 2010
Subject: [GHC] #3729: Allow modification of capabilities at runtime
In-Reply-To: <047.1fc6c652629dc9260c76c16a8c0a5af6@abbot.galois.com>
References: <047.1fc6c652629dc9260c76c16a8c0a5af6@abbot.galois.com>
Message-ID: <056.6391794bc00422b852461e68cbdab4b7@abbot.galois.com>

#3729: Allow modification of capabilities at runtime
---------------------------------+------------------------------------------
    Reporter:  mlesniak          |        Owner:              
        Type:  task              |       Status:  new         
    Priority:  normal            |    Milestone:  6.14 branch 
   Component:  Runtime System    |      Version:  6.13        
    Keywords:  capabilities      |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.14 branch


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3729#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 15:33:47 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 15:07:13 2010
Subject: [GHC] #3726: Internal error compiling ghc-syb-0.1.2.1
In-Reply-To: <052.a180cd251b9bcdf1661af16494dfc00b@abbot.galois.com>
References: <052.a180cd251b9bcdf1661af16494dfc00b@abbot.galois.com>
Message-ID: <061.3da725fdee30cb71ccd45cf8a37b6b7a@abbot.galois.com>

#3726: Internal error compiling ghc-syb-0.1.2.1
---------------------------------+------------------------------------------
    Reporter:  DavidHalperin     |        Owner:                    
        Type:  bug               |       Status:  new               
    Priority:  normal            |    Milestone:                    
   Component:  Compiler          |      Version:  6.10.4            
    Keywords:                    |   Difficulty:                    
          Os:  Unknown/Multiple  |     Testcase:                    
Architecture:  Unknown/Multiple  |      Failure:  Compile-time crash
---------------------------------+------------------------------------------
Description changed by igloo:

Old description:

> On Ubuntu Karmic x86_64 (installed from the apt repo), when I try to
> compile the ghc-syb-0.1.2.1 package I get the following output:
>
> Building ghc-syb-0.1.2.1...[[BR]]
> [1 of 2] Compiling GHC.SYB.Instances ( src/GHC/SYB/Instances.hs,
> dist/build/GHC/SYB/Instances.o )[[BR]]
> ghc: internal error: evacuate: strange closure type 13771848
>     (GHC version 6.10.4 for x86_64_unknown_linux)
>     Please report this as a GHC bug:
> http://www.haskell.org/ghc/reportabug

New description:

 On Ubuntu Karmic x86_64 (installed from the apt repo), when I try to
 compile the ghc-syb-0.1.2.1 package I get the following output:
 {{{
 Building ghc-syb-0.1.2.1...
 [1 of 2] Compiling GHC.SYB.Instances ( src/GHC/SYB/Instances.hs,
 dist/build/GHC/SYB/Instances.o )
 ghc: internal error: evacuate: strange closure type 13771848
     (GHC version 6.10.4 for x86_64_unknown_linux)
     Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug
 }}}

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3726#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 15:41:16 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 15:14:42 2010
Subject: [GHC] #3726: Internal error compiling ghc-syb-0.1.2.1
In-Reply-To: <052.a180cd251b9bcdf1661af16494dfc00b@abbot.galois.com>
References: <052.a180cd251b9bcdf1661af16494dfc00b@abbot.galois.com>
Message-ID: <061.21c9d124f0dd2a7c67077b42cc086687@abbot.galois.com>

#3726: Internal error compiling ghc-syb-0.1.2.1
---------------------------------+------------------------------------------
    Reporter:  DavidHalperin     |        Owner:                    
        Type:  bug               |       Status:  new               
    Priority:  normal            |    Milestone:  6.12.2            
   Component:  Compiler          |      Version:  6.10.4            
    Keywords:                    |   Difficulty:                    
          Os:  Unknown/Multiple  |     Testcase:                    
Architecture:  Unknown/Multiple  |      Failure:  Compile-time crash
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


Comment:

 Thanks for the report.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3726#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 15:57:13 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 15:30:40 2010
Subject: [GHC] #3725: Annotations not written to interface files
In-Reply-To: <041.dfa4280aa188470f7b07eff4da2beab3@abbot.galois.com>
References: <041.dfa4280aa188470f7b07eff4da2beab3@abbot.galois.com>
Message-ID: <050.dfec386c02dd35786564c8d7eea5b733@abbot.galois.com>

#3725: Annotations not written to interface files
---------------------------------+------------------------------------------
    Reporter:  rl                |        Owner:        
        Type:  bug               |       Status:  new   
    Priority:  normal            |    Milestone:  6.12.2
   Component:  Compiler          |      Version:  6.13  
    Keywords:                    |   Difficulty:        
          Os:  Unknown/Multiple  |     Testcase:        
Architecture:  Unknown/Multiple  |      Failure:  Other 
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3725#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 15:58:18 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 15:31:44 2010
Subject: [GHC] #3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when
 loading module
In-Reply-To: <044.c8fe00d0df86676aef8470e80da77abf@abbot.galois.com>
References: <044.c8fe00d0df86676aef8470e80da77abf@abbot.galois.com>
Message-ID: <053.b7386c6a52075d0e04255cddbd2c2ee5@abbot.galois.com>

#3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when loading module
----------------------+-----------------------------------------------------
  Reporter:  fasta    |          Owner:                  
      Type:  bug      |         Status:  closed          
  Priority:  normal   |      Milestone:                  
 Component:  GHCi     |        Version:  6.10.4          
Resolution:  invalid  |       Keywords:                  
Difficulty:           |             Os:  Unknown/Multiple
  Testcase:           |   Architecture:  Unknown/Multiple
   Failure:  Other    |  
----------------------+-----------------------------------------------------
Changes (by igloo):

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


Comment:

 No reply from submitter, so closing ticket.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3720#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 16:00:25 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 15:33:57 2010
Subject: [GHC] #3714: Improve error message if an associated family
 declaration has excess parameters
In-Reply-To: <046.1269d7611bd6a1dfa394e0799eb1571c@abbot.galois.com>
References: <046.1269d7611bd6a1dfa394e0799eb1571c@abbot.galois.com>
Message-ID: <055.dea5d23edbadd4522c03f648609e898e@abbot.galois.com>

#3714: Improve error message if an associated family declaration has excess
parameters
---------------------------------+------------------------------------------
    Reporter:  simonpj           |        Owner:  chak        
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  6.14.1      
   Component:  Compiler          |      Version:  6.10.4      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.14.1


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3714#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 16:26:07 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 15:59:34 2010
Subject: [GHC] #3733: When I loaded a file and ran it,
 it gave a message asking me to submit a bug
In-Reply-To: <046.6eb3b07bda483d4af283b08f7d4cde7a@abbot.galois.com>
References: <046.6eb3b07bda483d4af283b08f7d4cde7a@abbot.galois.com>
Message-ID: <055.407ec3c88ab395005af8aae321a7966a@abbot.galois.com>

#3733: When I loaded a file and ran it, it gave a message asking me to submit a
bug
-------------------------+--------------------------------------------------
    Reporter:  vtrajan   |        Owner:              
        Type:  bug       |       Status:  new         
    Priority:  normal    |    Milestone:              
   Component:  Compiler  |      Version:  6.10.4      
    Keywords:            |   Difficulty:              
          Os:  Windows   |     Testcase:              
Architecture:  x86       |      Failure:  None/Unknown
-------------------------+--------------------------------------------------
Description changed by igloo:

Old description:

> I wrote the program evaluator1.hs from "Scheme Interpreter in 48 hours"
> tutorial.  I loaded it into GHCi and ran Number 1.  It gave a message:
> :panic! (the 'impossible' happened)
> (GHC version 6.10.1 for i386-unknow-mingw32):
>    loadObj: failed
>
> please report this as a GHC bug:  http:...

New description:

 I wrote the program evaluator1.hs from "Scheme Interpreter in 48 hours"
 tutorial.  I loaded it into GHCi and ran Number 1.  It gave a message:
 {{{
 :panic! (the 'impossible' happened)
 (GHC version 6.10.1 for i386-unknow-mingw32):
    loadObj: failed

 please report this as a GHC bug:  http:...
 }}}

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3733#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 16:26:52 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 16:00:21 2010
Subject: [GHC] #3733: When I loaded a file and ran it,
 it gave a message asking me to submit a bug
In-Reply-To: <046.6eb3b07bda483d4af283b08f7d4cde7a@abbot.galois.com>
References: <046.6eb3b07bda483d4af283b08f7d4cde7a@abbot.galois.com>
Message-ID: <055.018b0e273070bedb0c6dd65c55a0849a@abbot.galois.com>

#3733: When I loaded a file and ran it, it gave a message asking me to submit a
bug
---------------------------+------------------------------------------------
  Reporter:  vtrajan       |          Owner:         
      Type:  bug           |         Status:  closed 
  Priority:  normal        |      Milestone:         
 Component:  Compiler      |        Version:  6.10.4 
Resolution:  invalid       |       Keywords:         
Difficulty:                |             Os:  Windows
  Testcase:                |   Architecture:  x86    
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by igloo):

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


Comment:

 No reply from submitter, so closing this ticket.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3733#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 16:37:41 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 16:11:07 2010
Subject: [GHC] #3743: type checker fails to infer an implicit parameter
 constraint in the presence of existential types.
In-Reply-To: <044.3ae86540a9a2f370a09cfac1cd97e512@abbot.galois.com>
References: <044.3ae86540a9a2f370a09cfac1cd97e512@abbot.galois.com>
Message-ID: <053.0b9a2e40bcf45515cd2eac61116065c7@abbot.galois.com>

#3743: type checker fails to infer an implicit parameter constraint in the
presence of existential types.
---------------------------------+------------------------------------------
    Reporter:  int-e             |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  6.14.1      
   Component:  Compiler          |      Version:  6.13        
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.14.1


Comment:

 Thanks for the report. I'm not sure if it is a bug or not, but we should
 work it out for 6.14.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3743#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 16:45:49 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 16:19:20 2010
Subject: [GHC] #3744: Comparisons against minBound/maxBound not optimised
In-Reply-To: <041.2169b48b8108c3b700385a622d1921fe@abbot.galois.com>
References: <041.2169b48b8108c3b700385a622d1921fe@abbot.galois.com>
Message-ID: <050.b0764ed52cb9e7c1e26ce8b237398313@abbot.galois.com>

#3744: Comparisons against minBound/maxBound not optimised
---------------------------------+------------------------------------------
    Reporter:  rl                |        Owner:                         
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  6.14 branch            
   Component:  Compiler          |      Version:  6.13                   
    Keywords:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.14 branch


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3744#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 16:47:37 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 16:21:06 2010
Subject: [GHC] #3802: :main in GHCi doesn't do getArgs wildcard expansion
In-Reply-To: <051.9313883e0b6179d02dcd32988e44001c@abbot.galois.com>
References: <051.9313883e0b6179d02dcd32988e44001c@abbot.galois.com>
Message-ID: <060.fadde73f85867dfcc30106c116b25163@abbot.galois.com>

#3802: :main in GHCi doesn't do getArgs wildcard expansion
------------------------------------------+---------------------------------
  Reporter:  NeilMitchell                 |          Owner:                  
      Type:  bug                          |         Status:  closed          
  Priority:  normal                       |      Milestone:                  
 Component:  GHCi                         |        Version:  6.12.1          
Resolution:  invalid                      |       Keywords:                  
Difficulty:                               |             Os:  Windows         
  Testcase:                               |   Architecture:  Unknown/Multiple
   Failure:  Incorrect result at runtime  |  
------------------------------------------+---------------------------------
Changes (by NeilMitchell):

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


Comment:

 It would certainly be convenient for {{{:main}}} to work as I described,
 but there are arguments both ways, so I'm resolving as invalid.

 If people do want this behaviour, they can always redefine the {{{:main}}}
 command in GHCi, which is probably what I'll do.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3802#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 16:53:18 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 16:26:46 2010
Subject: [GHC] #3746: Poor parse error
In-Reply-To: <051.30594b4d5bf93a82dda06cabe9760a79@abbot.galois.com>
References: <051.30594b4d5bf93a82dda06cabe9760a79@abbot.galois.com>
Message-ID: <060.b2736a041b179ee0bf72606b8c7d905a@abbot.galois.com>

#3746: Poor parse error
---------------------------------+------------------------------------------
    Reporter:  NeilMitchell      |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  6.14 branch 
   Component:  Compiler          |      Version:  6.10.4      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.14 branch


Comment:

 Thanks for the example.

 HEAD gives the same error (although the column numbers are now 1
 different):
 {{{
 h.hs:1:10: Parse error in pattern
 }}}
 but if you give the `-ferror-spans` flag then you get:
 {{{
 h.hs:(1,10)-(10,17): Parse error in pattern
 }}}
 (10:17 is the "a"). Perhaps the error message should be changed anyway,
 but I think this is an example of where having `-ferror-spans` on by
 default would be helpful.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3746#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 16:59:04 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 16:32:45 2010
Subject: [GHC] #3748: Bug in rts/Win32/Ticker.c can cause process hang
 on exit in Win32
In-Reply-To: <042.ebc1303ba4ba1bb01245ae57d2b8c614@abbot.galois.com>
References: <042.ebc1303ba4ba1bb01245ae57d2b8c614@abbot.galois.com>
Message-ID: <051.f02f144c25a01306cb54ed5a667adfa2@abbot.galois.com>

#3748: Bug in rts/Win32/Ticker.c can cause process hang on exit in Win32
---------------------------------+------------------------------------------
    Reporter:  sgf               |        Owner:               
        Type:  bug               |       Status:  new          
    Priority:  normal            |    Milestone:  6.12.2       
   Component:  Runtime System    |      Version:  6.10.4       
    Keywords:                    |   Difficulty:               
          Os:  Windows           |     Testcase:               
Architecture:  Unknown/Multiple  |      Failure:  Runtime crash
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3748#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 16:59:41 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 16:33:07 2010
Subject: [GHC] #3753: Make ghci's -l option consistent with GNU ld's -l
 option
In-Reply-To: <046.21a3b8e0ae623770f7106f301bc229f6@abbot.galois.com>
References: <046.21a3b8e0ae623770f7106f301bc229f6@abbot.galois.com>
Message-ID: <055.148fc11ce33c4efae11109e78f4517b9@abbot.galois.com>

#3753: Make ghci's -l option consistent with GNU ld's -l option
---------------------------------+------------------------------------------
    Reporter:  hgolden           |        Owner:              
        Type:  feature request   |       Status:  new         
    Priority:  normal            |    Milestone:  6.14.1      
   Component:  GHCi              |      Version:  6.12.1      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.14.1


Comment:

 Thanks for the suggestion.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3753#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 17:00:48 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 16:34:21 2010
Subject: [GHC] #3754: broken link in documentation
In-Reply-To: <068.11e88f7687fde0a8343b6e97dc1731e1@abbot.galois.com>
References: <068.11e88f7687fde0a8343b6e97dc1731e1@abbot.galois.com>
Message-ID: <077.f36a961dfcefb84d734e1e5246912366@abbot.galois.com>

#3754: broken link in documentation
--------------------------------------------+-------------------------------
  Reporter:  malcolm.wallace@?              |          Owner:                  
      Type:  bug                            |         Status:  closed          
  Priority:  normal                         |      Milestone:                  
 Component:  Documentation                  |        Version:  6.12.1          
Resolution:  fixed                          |       Keywords:                  
Difficulty:                                 |             Os:  Unknown/Multiple
  Testcase:                                 |   Architecture:  Unknown/Multiple
   Failure:  Documentation bug              |  
--------------------------------------------+-------------------------------
Changes (by igloo):

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


Comment:

 Thanks for the report; a symlink has been created so that the URL now
 exists.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3754#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 18:17:25 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 17:50:50 2010
Subject: [GHC] #3755: Improve join point inlining
In-Reply-To: <046.29f65772931b3d82df31cb86d07a2ef5@abbot.galois.com>
References: <046.29f65772931b3d82df31cb86d07a2ef5@abbot.galois.com>
Message-ID: <055.2bc26378bc41141e50ece274bd032628@abbot.galois.com>

#3755: Improve join point inlining
---------------------------------+------------------------------------------
    Reporter:  simonpj           |        Owner:                         
        Type:  task              |       Status:  new                    
    Priority:  normal            |    Milestone:  6.14.1                 
   Component:  Compiler          |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.14.1


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3755#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 18:17:45 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 17:51:08 2010
Subject: [GHC] #3759: -no-auto-link-packages flag isn't documented in
 User Guide
In-Reply-To: <046.f54a1b5f9a827c433057d50cad782105@abbot.galois.com>
References: <046.f54a1b5f9a827c433057d50cad782105@abbot.galois.com>
Message-ID: <055.8044a47c5031d362c9be1788e8451f41@abbot.galois.com>

#3759: -no-auto-link-packages flag isn't documented in User Guide
---------------------------------+------------------------------------------
    Reporter:  hgolden           |        Owner:                   
        Type:  bug               |       Status:  new              
    Priority:  normal            |    Milestone:  6.12.2           
   Component:  Documentation     |      Version:  6.12.1           
    Keywords:  flag              |   Difficulty:                   
          Os:  Unknown/Multiple  |     Testcase:                   
Architecture:  Unknown/Multiple  |      Failure:  Documentation bug
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


Comment:

 Thanks for the report.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3759#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 18:18:54 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 17:52:20 2010
Subject: [GHC] #3761: 6.12.1 HC bootstrap failes due to suspicious
 static library ordering
In-Reply-To: <042.d80ddfbea544695de9a61d32ac79b9bd@abbot.galois.com>
References: <042.d80ddfbea544695de9a61d32ac79b9bd@abbot.galois.com>
Message-ID: <051.670f832029b0fbce34f1e8983e5fb025@abbot.galois.com>

#3761: 6.12.1 HC bootstrap failes due to suspicious static library ordering
---------------------------------+------------------------------------------
    Reporter:  PHO               |        Owner:  igloo              
        Type:  bug               |       Status:  new                
    Priority:  normal            |    Milestone:  6.12.2             
   Component:  Build System      |      Version:  6.12.1             
    Keywords:                    |   Difficulty:                     
          Os:  Unknown/Multiple  |     Testcase:                     
Architecture:  Unknown/Multiple  |      Failure:  Building GHC failed
---------------------------------+------------------------------------------
Changes (by igloo):

  * owner:  => igloo
  * milestone:  => 6.12.2


Comment:

 Thanks for the report; I'll validate and apply.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3761#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 18:19:43 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 17:53:06 2010
Subject: [GHC] #3764: need --htmldir conifiguration
In-Reply-To: <050.747b1712677f28ce0bf9a45c7d03b30b@abbot.galois.com>
References: <050.747b1712677f28ce0bf9a45c7d03b30b@abbot.galois.com>
Message-ID: <059.a997f5c7c478e84da3eb6fdec89cb548@abbot.galois.com>

#3764: need --htmldir conifiguration
---------------------------------+------------------------------------------
    Reporter:  juhpetersen       |        Owner:  igloo       
        Type:  feature request   |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  Build System      |      Version:  6.12.1      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * owner:  => igloo
  * milestone:  => 6.12.2


Comment:

 Thanks for the report; I'll take a look.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3764#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 18:23:00 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 17:56:25 2010
Subject: [GHC] #3766: Parsing of lambdas is not consistent with
 Haskell'98 report.
In-Reply-To: <044.9158723b04d24d385ae3535f0b133db9@abbot.galois.com>
References: <044.9158723b04d24d385ae3535f0b133db9@abbot.galois.com>
Message-ID: <053.7517d5062464278924e84950ab736900@abbot.galois.com>

#3766: Parsing of lambdas is not consistent with Haskell'98 report.
----------------------------------+-----------------------------------------
    Reporter:  lilac              |        Owner:                           
        Type:  bug                |       Status:  new                      
    Priority:  normal             |    Milestone:  6.14.1                   
   Component:  Compiler (Parser)  |      Version:  6.10.4                   
    Keywords:                     |   Difficulty:                           
          Os:  Unknown/Multiple   |     Testcase:                           
Architecture:  Unknown/Multiple   |      Failure:  GHC rejects valid program
----------------------------------+-----------------------------------------
Changes (by igloo):

  * milestone:  => 6.14.1


Comment:

 Thanks for the report. We should either fix GHC or get an H' proposal
 written.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3766#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 19:09:33 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 18:42:58 2010
Subject: [GHC] #3768: 6.12.1 Mac OS X installer lacks all HTML
 documentation
In-Reply-To: <052.9cb08ea2ad1c2eaf3d32d7297cdfbef7@abbot.galois.com>
References: <052.9cb08ea2ad1c2eaf3d32d7297cdfbef7@abbot.galois.com>
Message-ID: <061.f55d0137039067a6bb2c359fbefcab22@abbot.galois.com>

#3768: 6.12.1 Mac OS X installer lacks all HTML documentation
------------------------------+---------------------------------------------
    Reporter:  Minimiscience  |        Owner:  igloo            
        Type:  bug            |       Status:  new              
    Priority:  normal         |    Milestone:  6.12.2           
   Component:  Documentation  |      Version:  6.12.1           
    Keywords:                 |   Difficulty:                   
          Os:  MacOS X        |     Testcase:                   
Architecture:  x86            |      Failure:  Documentation bug
------------------------------+---------------------------------------------
Changes (by igloo):

  * owner:  => igloo
  * milestone:  => 6.12.2


Comment:

 Thanks for the report; I'll take a look.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3768#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 19:10:05 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 18:43:31 2010
Subject: [GHC] #3769: Add manpages for programs installed alongside ghc
In-Reply-To: <052.9d14df9a6a2c1546285803fde0bb736d@abbot.galois.com>
References: <052.9d14df9a6a2c1546285803fde0bb736d@abbot.galois.com>
Message-ID: <061.8e0bca2764d5a3fb187fc627e4615da1@abbot.galois.com>

#3769: Add manpages for programs installed alongside ghc
-----------------------------------------------+----------------------------
    Reporter:  Minimiscience                   |        Owner:                   
        Type:  feature request                 |       Status:  new              
    Priority:  normal                          |    Milestone:                   
   Component:  Documentation                   |      Version:  6.12.1           
    Keywords:  manpage documentation manpages  |   Difficulty:                   
          Os:  Unknown/Multiple                |     Testcase:                   
Architecture:  Unknown/Multiple                |      Failure:  Documentation bug
-----------------------------------------------+----------------------------
Description changed by igloo:

Old description:

> The following programs installed with GHC (specifically, using the Mac OS
> X installer, though I suspect this applies to all platforms) do not have
> manpages:
>
> * `ghc-pkg`
> * `ghci` (Technically, its manpage is the same as `ghc`'s, but there's no
> `ghci.1` symlink to `ghc.1`, so `man ghci` fails to find anything.)
> * `haddock`
> * `hp2ps`
> * `hpc`
> * `hsc2hs`
> * `runghc`
> * `runhaskell`
>
> I think that's all of them.
>
> I realize that not all of these programs (e.g., `haddock`) are truly part
> of GHC, but the ones that are still need manpages.  If the problem is
> that writing *roff is hard, and you don't mind mooching off other
> languages, might I refer you to [http://perldoc.perl.org/perlpod.html
> POD]/[http://perldoc.perl.org/pod2man.html pod2man]?

New description:

 The following programs installed with GHC (specifically, using the Mac OS
 X installer, though I suspect this applies to all platforms) do not have
 manpages:

  * `ghc-pkg`
  * `ghci` (Technically, its manpage is the same as `ghc`'s, but there's no
 `ghci.1` symlink to `ghc.1`, so `man ghci` fails to find anything.)
  * `haddock`
  * `hp2ps`
  * `hpc`
  * `hsc2hs`
  * `runghc`
  * `runhaskell`

 I think that's all of them.

 I realize that not all of these programs (e.g., `haddock`) are truly part
 of GHC, but the ones that are still need manpages.  If the problem is that
 writing *roff is hard, and you don't mind mooching off other languages,
 might I refer you to [http://perldoc.perl.org/perlpod.html
 POD]/[http://perldoc.perl.org/pod2man.html pod2man]?

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3769#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 19:16:16 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 18:49:42 2010
Subject: [GHC] #3769: Add manpages for programs installed alongside ghc
In-Reply-To: <052.9d14df9a6a2c1546285803fde0bb736d@abbot.galois.com>
References: <052.9d14df9a6a2c1546285803fde0bb736d@abbot.galois.com>
Message-ID: <061.0acf89b642ee9c0c6e3d4eb84b214aa4@abbot.galois.com>

#3769: Add manpages for programs installed alongside ghc
-----------------------------------------------+----------------------------
    Reporter:  Minimiscience                   |        Owner:                   
        Type:  feature request                 |       Status:  new              
    Priority:  normal                          |    Milestone:  _|_              
   Component:  Documentation                   |      Version:  6.12.1           
    Keywords:  manpage documentation manpages  |   Difficulty:                   
          Os:  Unknown/Multiple                |     Testcase:                   
Architecture:  Unknown/Multiple                |      Failure:  Documentation bug
-----------------------------------------------+----------------------------
Changes (by igloo):

  * milestone:  => _|_


Comment:

 The real problem is adding the man pages in a way that doesn't
 significantly increase the maintenance burden.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3769#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 19:19:48 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 18:53:12 2010
Subject: [GHC] #3772: Methods not inlined
In-Reply-To: <041.149838f1167826da5472d3fc400a3e07@abbot.galois.com>
References: <041.149838f1167826da5472d3fc400a3e07@abbot.galois.com>
Message-ID: <050.77fbb7c2e83c19679b976609d9ea4316@abbot.galois.com>

#3772: Methods not inlined
---------------------------------+------------------------------------------
    Reporter:  rl                |        Owner:                         
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  6.12 branch            
   Component:  Compiler          |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12 branch


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3772#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 19:20:17 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 18:53:42 2010
Subject: [GHC] #3773: Haddoc documentation on wrong function argument
In-Reply-To: <044.635ed03af9d418169b269fce9db0718f@abbot.galois.com>
References: <044.635ed03af9d418169b269fce9db0718f@abbot.galois.com>
Message-ID: <053.50ff9391afe5f74e1977479f5dafab53@abbot.galois.com>

#3773: Haddoc documentation on wrong function argument
---------------------------------+------------------------------------------
    Reporter:  tibbe             |        Owner:  waern       
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  Documentation     |      Version:  6.10.4      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3773#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 19:25:24 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 18:58:48 2010
Subject: [GHC] #3777: Split MonaIO class from mtl
In-Reply-To: <052.0f80b9dfa9e67b3e80dc882bcdffe017@abbot.galois.com>
References: <052.0f80b9dfa9e67b3e80dc882bcdffe017@abbot.galois.com>
Message-ID: <061.cd82d8aeb258b443cda710ae4e083fb0@abbot.galois.com>

#3777: Split MonaIO class from mtl
----------------------------------+-----------------------------------------
    Reporter:  AntoineLatter      |        Owner:              
        Type:  proposal           |       Status:  new         
    Priority:  normal             |    Milestone:  Not GHC     
   Component:  libraries (other)  |      Version:  6.12.1      
    Keywords:                     |   Difficulty:              
          Os:  Unknown/Multiple   |     Testcase:              
Architecture:  Unknown/Multiple   |      Failure:  None/Unknown
----------------------------------+-----------------------------------------
Changes (by igloo):

  * milestone:  => Not GHC


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3777#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 19:27:42 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 19:01:09 2010
Subject: [GHC] #3781: Improve inlining for local functions
In-Reply-To: <046.7e7e45262f788675411974bac0244395@abbot.galois.com>
References: <046.7e7e45262f788675411974bac0244395@abbot.galois.com>
Message-ID: <055.69a9a2d48a626540f63512e4cb8731e5@abbot.galois.com>

#3781: Improve inlining for local functions
---------------------------------+------------------------------------------
    Reporter:  simonpj           |        Owner:                         
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  6.12 branch            
   Component:  Compiler          |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12 branch


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3781#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 19:27:54 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 19:01:21 2010
Subject: [GHC] #3782: Data Parallel "Impossible happened" compiler error
In-Reply-To: <044.3d41e65d193faf115a9d9aeea6bab909@abbot.galois.com>
References: <044.3d41e65d193faf115a9d9aeea6bab909@abbot.galois.com>
Message-ID: <053.f3d1172940669897fd077bc79522fdf7@abbot.galois.com>

#3782: Data Parallel "Impossible happened" compiler error
---------------------------------+------------------------------------------
    Reporter:  guest             |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:              
   Component:  Compiler          |      Version:  6.12.1      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Description changed by igloo:

Old description:

> When I attempted to compile my vectorized code , I got the following
> message:
>
> ghc -c -Odph -fcpr-off -fdph-seq newprop.hs
> ghc: panic! (the 'impossible' happened)
>   (GHC version 6.12.1 for i386-apple-darwin):
>         sumTyCon 11
>
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

New description:

 When I attempted to compile my vectorized code , I got the following
 message:
 {{{
 ghc -c -Odph -fcpr-off -fdph-seq newprop.hs
 ghc: panic! (the 'impossible' happened)
   (GHC version 6.12.1 for i386-apple-darwin):
         sumTyCon 11

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
 }}}

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3782#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 19:32:43 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 19:06:07 2010
Subject: [GHC] #3782: Data Parallel "Impossible happened" compiler error
In-Reply-To: <044.3d41e65d193faf115a9d9aeea6bab909@abbot.galois.com>
References: <044.3d41e65d193faf115a9d9aeea6bab909@abbot.galois.com>
Message-ID: <053.e9c978e2d6dcab1e1bf612c593b3e9d6@abbot.galois.com>

#3782: Data Parallel "Impossible happened" compiler error
--------------------------------------+-------------------------------------
    Reporter:  guest                  |        Owner:              
        Type:  bug                    |       Status:  new         
    Priority:  normal                 |    Milestone:  6.12.2      
   Component:  Data Parallel Haskell  |      Version:  6.12.1      
    Keywords:                         |   Difficulty:              
          Os:  Unknown/Multiple       |     Testcase:              
Architecture:  Unknown/Multiple       |      Failure:  None/Unknown
--------------------------------------+-------------------------------------
Changes (by igloo):

  * component:  Compiler => Data Parallel Haskell
  * milestone:  => 6.12.2


Comment:

 Thanks for the report. This also happens in the HEAD and 6.12 branches.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3782#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 19:40:00 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 19:13:25 2010
Subject: [GHC] #3784: --with-gmp-includes and --with-gmp-libraries don't
 affect the building process of
 integer-gmp/cbits/mkGmpDerivedConstants
In-Reply-To: <042.086ff891f8fafb9e8c853a08131127e3@abbot.galois.com>
References: <042.086ff891f8fafb9e8c853a08131127e3@abbot.galois.com>
Message-ID: <051.e3ff643b90516aa707edd6a7a5dee98f@abbot.galois.com>

#3784: --with-gmp-includes and --with-gmp-libraries don't affect the building
process of integer-gmp/cbits/mkGmpDerivedConstants
---------------------------------+------------------------------------------
    Reporter:  PHO               |        Owner:  igloo              
        Type:  bug               |       Status:  new                
    Priority:  normal            |    Milestone:  6.12.2             
   Component:  libraries/base    |      Version:  6.12.1             
    Keywords:  integer-gmp       |   Difficulty:                     
          Os:  Unknown/Multiple  |     Testcase:                     
Architecture:  Unknown/Multiple  |      Failure:  Building GHC failed
---------------------------------+------------------------------------------
Changes (by igloo):

  * owner:  => igloo
  * milestone:  => 6.12.2


Comment:

 Thanks for the report; I'll take a look.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3784#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 19:45:47 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 19:19:12 2010
Subject: [GHC] #3786: showing function argumetns when stopped at its
 definition
In-Reply-To: <046.1f009ea01681f500ec74b93e2a923cd9@abbot.galois.com>
References: <046.1f009ea01681f500ec74b93e2a923cd9@abbot.galois.com>
Message-ID: <055.768fc3e0bcfd98080805ec859d73e421@abbot.galois.com>

#3786: showing function argumetns when stopped at its definition
---------------------------------+------------------------------------------
    Reporter:  phercek           |        Owner:              
        Type:  feature request   |       Status:  new         
    Priority:  normal            |    Milestone:  6.14 branch 
   Component:  GHCi              |      Version:  6.12.1      
    Keywords:  debugger          |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.14 branch


Comment:

 Thanks for the suggestion.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3786#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 19:50:08 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 19:23:32 2010
Subject: [GHC] #3788: Improved message for GHC "No instance for" Errors
In-Reply-To: <048.485a2dc2f99474a564b523723eb1f48f@abbot.galois.com>
References: <048.485a2dc2f99474a564b523723eb1f48f@abbot.galois.com>
Message-ID: <057.7b6219eddb6f39ff7b2c46f71befdb67@abbot.galois.com>

#3788: Improved message for GHC "No instance for" Errors
---------------------------------+------------------------------------------
    Reporter:  rhapsodyv         |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  Compiler          |      Version:  6.10.4      
    Keywords:  errors            |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * type:  proposal => bug
  * milestone:  => 6.12.2


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3788#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 20:25:53 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 19:59:18 2010
Subject: [GHC] #3817: -fvia-C / mangler fails with gcc-4.3.x on sparc;
 suggest disabling -fvia-C
In-Reply-To: <045.763dbbac5925c7bf65ed54ed1092e47b@abbot.galois.com>
References: <045.763dbbac5925c7bf65ed54ed1092e47b@abbot.galois.com>
Message-ID: <054.83ae708eb596199e8ed52026dfed53cc@abbot.galois.com>

#3817: -fvia-C / mangler fails with gcc-4.3.x on sparc; suggest disabling -fvia-C
---------------------------------+------------------------------------------
    Reporter:  duncan            |        Owner:                         
        Type:  bug               |       Status:  new                    
    Priority:  low               |    Milestone:  6.12.2                 
   Component:  Driver            |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:  Easy (less than 1 hour)
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  sparc             |      Failure:  Runtime crash          
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3817#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 20:26:30 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 19:59:55 2010
Subject: [GHC] #3791: SplitObjs fails on sparc with GNU ld
In-Reply-To: <045.5e901b18df33895f26639fdfc0d17dcc@abbot.galois.com>
References: <045.5e901b18df33895f26639fdfc0d17dcc@abbot.galois.com>
Message-ID: <054.8cc9906263dbf6fe21733f746af559ad@abbot.galois.com>

#3791: SplitObjs fails on sparc with GNU ld
-----------------------+----------------------------------------------------
    Reporter:  duncan  |        Owner:                         
        Type:  bug     |       Status:  new                    
    Priority:  low     |    Milestone:  6.12.2                 
   Component:  Driver  |      Version:  6.12.1                 
    Keywords:          |   Difficulty:  Easy (less than 1 hour)
          Os:  Linux   |     Testcase:                         
Architecture:  sparc   |      Failure:  Building GHC failed    
-----------------------+----------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3791#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 20:30:36 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 20:04:00 2010
Subject: [GHC] #3816: System.Posix.GetAllGroupEntries returns 0 groups
 for 2nd and subsequent calls
In-Reply-To: <047.6ed51ca280e5f40fc20f0caf56b9b6f6@abbot.galois.com>
References: <047.6ed51ca280e5f40fc20f0caf56b9b6f6@abbot.galois.com>
Message-ID: <056.455957d5a0947f53e1497c96220c1785@abbot.galois.com>

#3816: System.Posix.GetAllGroupEntries returns 0 groups for 2nd and subsequent
calls
------------------------------------------------+---------------------------
    Reporter:  tphyahoo                         |        Owner:                
        Type:  bug                              |       Status:  new           
    Priority:  normal                           |    Milestone:  6.12.2        
   Component:  Compiler                         |      Version:  6.10.4        
    Keywords:  groups getAllGroupentries posix  |   Difficulty:  Unknown       
          Os:  Linux                            |     Testcase:  in description
Architecture:  x86_64 (amd64)                   |      Failure:  None/Unknown  
------------------------------------------------+---------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


Comment:

 Still happens in HEAD and 6.12.
 {{{
 Prelude> :m + System.Posix Control.Monad
 Prelude System.Posix Control.Monad> liftM length getAllGroupEntries
 Loading package unix-2.4.0.0 ... linking ... done.
 63
 Prelude System.Posix Control.Monad> liftM length getAllGroupEntries
 0
 Prelude System.Posix Control.Monad>
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3816#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 20:34:49 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 20:08:14 2010
Subject: [GHC] #3813: Invalid warning from GHCi
In-Reply-To: <051.207c96ece971d6767ecb4b1e779ba7b2@abbot.galois.com>
References: <051.207c96ece971d6767ecb4b1e779ba7b2@abbot.galois.com>
Message-ID: <060.513b3d27438f92c80a7a89ccb328a89d@abbot.galois.com>

#3813: Invalid warning from GHCi
---------------------------------+------------------------------------------
    Reporter:  NeilMitchell      |        Owner:                                   
        Type:  bug               |       Status:  new                              
    Priority:  normal            |    Milestone:  6.12.2                           
   Component:  GHCi              |      Version:  6.10.4                           
    Keywords:                    |   Difficulty:                                   
          Os:  Unknown/Multiple  |     Testcase:                                   
Architecture:  Unknown/Multiple  |      Failure:  Incorrect warning at compile-time
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


Comment:

 Thanks for the report

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3813#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 13 20:36:38 2010
From: trac at galois.com (GHC)
Date: Wed Jan 13 20:10:05 2010
Subject: [GHC] #3809: template-haskell 2.4 fails to compile with base 4.1
In-Reply-To: <049.ca9219b06862df97bec4403d1ce919ca@abbot.galois.com>
References: <049.ca9219b06862df97bec4403d1ce919ca@abbot.galois.com>
Message-ID: <058.70b521c93ef12ac6095afea34f08ae2b@abbot.galois.com>

#3809: template-haskell 2.4 fails to compile with base 4.1
----------------------------------+-----------------------------------------
    Reporter:  benmachine         |        Owner:  igloo 
        Type:  bug                |       Status:  new   
    Priority:  normal             |    Milestone:  6.12.2
   Component:  libraries (other)  |      Version:  6.10.4
    Keywords:                     |   Difficulty:        
          Os:  Unknown/Multiple   |     Testcase:        
Architecture:  Unknown/Multiple   |      Failure:  Other 
----------------------------------+-----------------------------------------
Changes (by igloo):

  * owner:  => igloo
  * milestone:  => 6.12.2


Comment:

 Thanks for the report. I'll bump the deps.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3809#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 03:31:06 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 03:04:30 2010
Subject: [GHC] #3772: Methods not inlined
In-Reply-To: <041.149838f1167826da5472d3fc400a3e07@abbot.galois.com>
References: <041.149838f1167826da5472d3fc400a3e07@abbot.galois.com>
Message-ID: <050.b2b4dfcd4df814d54cf7d69442e34cbd@abbot.galois.com>

#3772: Methods not inlined
---------------------------------------------+------------------------------
  Reporter:  rl                              |          Owner:                  
      Type:  bug                             |         Status:  closed          
  Priority:  normal                          |      Milestone:  6.12 branch     
 Component:  Compiler                        |        Version:  6.12.1          
Resolution:  fixed                           |       Keywords:                  
Difficulty:                                  |             Os:  Unknown/Multiple
  Testcase:  simplCore/should_compile/T3772  |   Architecture:  Unknown/Multiple
   Failure:  Runtime performance bug         |  
---------------------------------------------+------------------------------
Changes (by simonpj):

  * status:  new => closed
  * testcase:  => simplCore/should_compile/T3772
  * resolution:  => fixed


Comment:

 Actually I fixed this one but forgot to update Trac:
 {{{
 Tue Jan  5 10:16:00 GMT 2010  simonpj@microsoft.com
   * Undo the fix for Trac #3772 and do it a new way

   The main idea is that I'm now treating a single-method dictionary very
   much like a multi-method dictionary.  In particular, it respond to
   exprIsConApp_maybe, even though newtypes aren't *really* proper
   constructors.

   See long comments with Note [Single-method classes] for why
   this slight hack is justified.

     M ./compiler/basicTypes/MkId.lhs -8 +4
     M ./compiler/typecheck/TcInstDcls.lhs -25 +67

 Mon Dec 21 16:04:31 GMT 2009  simonpj@microsoft.com
   * Fix Trac #3772: dict funs for single-field classes

   This patch fixes a bug that meant that INLINE pragamas on
   a method of a single-field class didn't work properly.

   See Note [Single-method classes] in TcInstDcls, and Trac #3772

     M ./compiler/typecheck/TcInstDcls.lhs -34 +61
 }}}
 There's a test in the regression suite.  Do not attempt to merge to 6.12;
 the code base is very different in this respect.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3772#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 03:40:12 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 03:13:36 2010
Subject: [GHC] #3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when
 loading module
In-Reply-To: <044.c8fe00d0df86676aef8470e80da77abf@abbot.galois.com>
References: <044.c8fe00d0df86676aef8470e80da77abf@abbot.galois.com>
Message-ID: <053.39870b2b92764d9661303ccf178dd688@abbot.galois.com>

#3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when loading module
---------------------+------------------------------------------------------
  Reporter:  fasta   |          Owner:                  
      Type:  bug     |         Status:  reopened        
  Priority:  normal  |      Milestone:                  
 Component:  GHCi    |        Version:  6.10.4          
Resolution:          |       Keywords:                  
Difficulty:          |             Os:  Unknown/Multiple
  Testcase:          |   Architecture:  Unknown/Multiple
   Failure:  Other   |  
---------------------+------------------------------------------------------
Changes (by fasta):

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


Comment:

 Replying to [comment:3 igloo]:
 > No reply from submitter, so closing ticket.
 This website has been down for days, so while I tried to respond, there
 was no way to do so other than via IRC, which I did. Checking every single
 day whether the system already works in a polling way is a waste of time
 for me.

 Anyway, I get this on Ubuntu 9.10 without any special configuration.

 The bug is simply in some code which searches for _GLOBAL_OFFSET_TABLE_
 and uses existing object files as an optimization. If before every use
 first all object files would be deleted, then this bug would not exist. It
 would be terribly slow, but it would be correct.

 I tried to reproduce a minimal case, but I failed in doing so. I would say
 that it happens once every month or so.

 So, marking this as invalid, simply because I didn't respond (which I
 did), would be wrong also for the simple matter that ghci produced a
 message, which it should not create, unless you think I am making this
 stuff up, in which case I should better just stop writing bug reports.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3720#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 03:48:12 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 03:21:36 2010
Subject: [GHC] #3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when
 loading module
In-Reply-To: <044.c8fe00d0df86676aef8470e80da77abf@abbot.galois.com>
References: <044.c8fe00d0df86676aef8470e80da77abf@abbot.galois.com>
Message-ID: <053.d84a648838a819a69c7a33854da33685@abbot.galois.com>

#3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when loading module
---------------------+------------------------------------------------------
  Reporter:  fasta   |          Owner:                  
      Type:  bug     |         Status:  reopened        
  Priority:  normal  |      Milestone:                  
 Component:  GHCi    |        Version:  6.10.4          
Resolution:          |       Keywords:                  
Difficulty:          |             Os:  Unknown/Multiple
  Testcase:          |   Architecture:  Unknown/Multiple
   Failure:  Other   |  
---------------------+------------------------------------------------------

Comment(by simonpj):

 Nobody is suggesting that you are making stuff up, or that the problem
 doesn't exist.  On the contrary we rely on users reporting bugs, and it's
 incredibly helpful that you do.

 It's just that if we can't reproduce a problem we can't fix it.  That
 doesn't mean there's no problem; it just means its' a problem we don't
 have a way to fix.  Perhaps "wontfix" (because can't reproduce) would have
 been a better setting than "invalid" for the "resolution" field in such
 cases.

 GHC's Trac has indeed been flaky for a week or two.  I'm sorry about that.
 Happily we are now running on a brand new machine, so things should be
 much better now.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3720#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 04:07:32 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 03:40:56 2010
Subject: [GHC] #3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when
 loading module
In-Reply-To: <044.c8fe00d0df86676aef8470e80da77abf@abbot.galois.com>
References: <044.c8fe00d0df86676aef8470e80da77abf@abbot.galois.com>
Message-ID: <053.e6b0a33ce50f0ca2827a331d84c5bb1d@abbot.galois.com>

#3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when loading module
----------------------+-----------------------------------------------------
  Reporter:  fasta    |          Owner:                  
      Type:  bug      |         Status:  closed          
  Priority:  normal   |      Milestone:                  
 Component:  GHCi     |        Version:  6.10.4          
Resolution:  wontfix  |       Keywords:                  
Difficulty:           |             Os:  Unknown/Multiple
  Testcase:           |   Architecture:  Unknown/Multiple
   Failure:  Other    |  
----------------------+-----------------------------------------------------
Changes (by fasta):

  * status:  reopened => closed
  * resolution:  => wontfix


Comment:

 Ok, maybe adding another type of resolution expressing this information
 would then be useful? Thank you for the clarification. I closed the ticket
 now.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3720#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 04:12:00 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 03:45:24 2010
Subject: [GHC] #3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when
 loading module
In-Reply-To: <044.c8fe00d0df86676aef8470e80da77abf@abbot.galois.com>
References: <044.c8fe00d0df86676aef8470e80da77abf@abbot.galois.com>
Message-ID: <053.78e2558374d919c749144c5c8cc7ba3f@abbot.galois.com>

#3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when loading module
----------------------+-----------------------------------------------------
  Reporter:  fasta    |          Owner:                  
      Type:  bug      |         Status:  closed          
  Priority:  normal   |      Milestone:                  
 Component:  GHCi     |        Version:  6.10.4          
Resolution:  wontfix  |       Keywords:                  
Difficulty:           |             Os:  Unknown/Multiple
  Testcase:           |   Architecture:  Unknown/Multiple
   Failure:  Other    |  
----------------------+-----------------------------------------------------

Comment(by simonpj):

 Yes, perhaps an "unable to reproduce" resolution.

 S

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3720#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 04:38:02 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 04:11:38 2010
Subject: [GHC] #3743: type checker fails to infer an implicit parameter
 constraint in the presence of existential types.
In-Reply-To: <044.3ae86540a9a2f370a09cfac1cd97e512@abbot.galois.com>
References: <044.3ae86540a9a2f370a09cfac1cd97e512@abbot.galois.com>
Message-ID: <053.039f5bd00d1b258c4bbd8342474cc077@abbot.galois.com>

#3743: type checker fails to infer an implicit parameter constraint in the
presence of existential types.
---------------------------------+------------------------------------------
    Reporter:  int-e             |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  6.14.1      
   Component:  Compiler          |      Version:  6.13        
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by simonpj):

 Interesting example.  Somehow I missed this bug when you first submitted
 it.

 Any type inference under local constraints is tricky.  See our paper "Let
 should not be generalised".  In the type system of that paper the program
 would be rejected on the grounds that we can't solve the implication
 {{{
   forall a. Foo a => (?x::())
 }}}
 But in this case there's an obvious simple constraint we could infer.
 I'll discuss with Dimitrios, and add it to my list for the new constraint
 solver.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3743#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 05:39:29 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:12:56 2010
Subject: [GHC] #3792: Qualified names in import specifications
In-Reply-To: <044.0afdfc1c49ec255d82e9097f816e7649@abbot.galois.com>
References: <044.0afdfc1c49ec255d82e9097f816e7649@abbot.galois.com>
Message-ID: <053.ec1e2d99b2bb45db1eefb7e763715e64@abbot.galois.com>

#3792: Qualified names in import specifications
---------------------------------+------------------------------------------
    Reporter:  nibro             |        Owner:  igloo                   
        Type:  merge             |       Status:  new                     
    Priority:  normal            |    Milestone:  6.12.2                  
   Component:  Compiler          |      Version:  6.12.1                  
    Keywords:                    |   Difficulty:                          
          Os:  Unknown/Multiple  |     Testcase:  rename/should_fail/T3792
Architecture:  Unknown/Multiple  |      Failure:  Other                   
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3792#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 05:40:05 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:13:29 2010
Subject: [GHC] #3794: Compiling a main program yields: /usr/bin/ld:
 cannot find -lHSrtsmain
In-Reply-To: <044.e1a190f33d758a6bb97e24503af072e1@abbot.galois.com>
References: <044.e1a190f33d758a6bb97e24503af072e1@abbot.galois.com>
Message-ID: <053.8bcd452d45c42cf5d2f8f3a37dba7def@abbot.galois.com>

#3794: Compiling a main program yields: /usr/bin/ld: cannot find -lHSrtsmain
-----------------------------+----------------------------------------------
    Reporter:  guest         |        Owner:  igloo                
        Type:  bug           |       Status:  new                  
    Priority:  normal        |    Milestone:  6.12.2               
   Component:  Build System  |      Version:  6.12.1               
    Keywords:                |   Difficulty:                       
          Os:  Linux         |     Testcase:                       
Architecture:  x86           |      Failure:  Installing GHC failed
-----------------------------+----------------------------------------------
Changes (by igloo):

  * owner:  => igloo
  * milestone:  => 6.12.2


Comment:

 Thanks for the report. I'll take a look.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3794#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 05:40:45 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:14:09 2010
Subject: [GHC] #3795: Haddock executable not versioned
In-Reply-To: <046.6038e00fcfe0d713d23c23af281a15cb@abbot.galois.com>
References: <046.6038e00fcfe0d713d23c23af281a15cb@abbot.galois.com>
Message-ID: <055.c56978d370d4e76b290c7dd241f5ce15@abbot.galois.com>

#3795: Haddock executable not versioned
---------------------------------+------------------------------------------
    Reporter:  lpsmith           |        Owner:        
        Type:  bug               |       Status:  new   
    Priority:  normal            |    Milestone:  6.12.2
   Component:  Documentation     |      Version:  6.12.1
    Keywords:                    |   Difficulty:        
          Os:  Unknown/Multiple  |     Testcase:        
Architecture:  Unknown/Multiple  |      Failure:  Other 
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


Comment:

 Thanks for the report.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3795#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 05:41:04 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:14:31 2010
Subject: [GHC] #3798: Problem with wxHaskell
In-Reply-To: <047.492dda442ff44524f4a71fea7b399885@abbot.galois.com>
References: <047.492dda442ff44524f4a71fea7b399885@abbot.galois.com>
Message-ID: <056.09b614d454206187038368a367ee898d@abbot.galois.com>

#3798: Problem with wxHaskell
---------------------------------+------------------------------------------
    Reporter:  MNorrish          |        Owner:        
        Type:  bug               |       Status:  new   
    Priority:  normal            |    Milestone:        
   Component:  Compiler          |      Version:  6.10.4
    Keywords:                    |   Difficulty:        
          Os:  Linux             |     Testcase:        
Architecture:  Unknown/Multiple  |      Failure:  Other 
---------------------------------+------------------------------------------
Description changed by igloo:

Old description:

> Hello.hs is a GUI hello world program I copied and pasted off
> http://en.wikibooks.org/wiki/Haskell/GUI. I have wxHaskell and ghc, and
> my attempt to compile it gives
>
> mark@mark-laptop:~/MyCode$ ghc -package wx Hello.hs -o bin
> Binary: Int64 truncated to fit in 32 bit Int
> ghc: panic! (the 'impossible' happened)
>   (GHC version 6.10.4 for i386-unknown-linux):
>         Prelude.chr: bad argument
>
> Meanwhile, running it off ghci gives a series of successfully linked and
> loaded packages, terminating with
>
> Loading package wxdirect-0.12.1.1 ... linking ... done.
> Loading package wxcore-0.12.1.2 ... <command line>: can't load .so/.DLL
> for: stdc++ (libstdc++.so: cannot open shared object file: No such file
> or directory)
>
> (I put type of failure as other because it's a GHC panic and a GHCi
> failure and probably some other sort of bug too.)

New description:

 Hello.hs is a GUI hello world program I copied and pasted off
 http://en.wikibooks.org/wiki/Haskell/GUI. I have wxHaskell and ghc, and my
 attempt to compile it gives
 {{{
 mark@mark-laptop:~/MyCode$ ghc -package wx Hello.hs -o bin
 Binary: Int64 truncated to fit in 32 bit Int
 ghc: panic! (the 'impossible' happened)
   (GHC version 6.10.4 for i386-unknown-linux):
         Prelude.chr: bad argument
 }}}
 Meanwhile, running it off ghci gives a series of successfully linked and
 loaded packages, terminating with
 {{{
 Loading package wxdirect-0.12.1.1 ... linking ... done.
 Loading package wxcore-0.12.1.2 ... <command line>: can't load .so/.DLL
 for: stdc++ (libstdc++.so: cannot open shared object file: No such file or
 directory)
 }}}
 (I put type of failure as other because it's a GHC panic and a GHCi
 failure and probably some other sort of bug too.)

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3798#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 05:43:18 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:16:43 2010
Subject: [GHC] #3798: Problem with wxHaskell
In-Reply-To: <047.492dda442ff44524f4a71fea7b399885@abbot.galois.com>
References: <047.492dda442ff44524f4a71fea7b399885@abbot.galois.com>
Message-ID: <056.ad460e290d0e3540ff8f53499482604f@abbot.galois.com>

#3798: Problem with wxHaskell
---------------------------------+------------------------------------------
    Reporter:  MNorrish          |        Owner:        
        Type:  bug               |       Status:  new   
    Priority:  normal            |    Milestone:  6.12.2
   Component:  Compiler          |      Version:  6.10.4
    Keywords:                    |   Difficulty:        
          Os:  Linux             |     Testcase:        
Architecture:  Unknown/Multiple  |      Failure:  Other 
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


Comment:

 Thanks for the report.

 I think this is the program:
 {{{
 module Main where

 import Graphics.UI.WX

 main :: IO ()
 main = start gui

 gui :: IO ()
 gui = do
   frame [text := "Hello World!"]
   return ()
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3798#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 05:50:29 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:23:54 2010
Subject: [GHC] #3799: undefined symbols and undefined references
 possibly related to template haskell
In-Reply-To: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
References: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
Message-ID: <058.09ba4b4f3f1340b6704a84d3ce150995@abbot.galois.com>

#3799: undefined symbols and undefined references possibly related to template
haskell
--------------------------------------------------------------+-------------
    Reporter:  JeremyShaw                                     |        Owner:                    
        Type:  bug                                            |       Status:  new               
    Priority:  normal                                         |    Milestone:  6.12.2            
   Component:  Compiler                                       |      Version:  6.13              
    Keywords:  undefined symbols references template haskell  |   Difficulty:                    
          Os:  Unknown/Multiple                               |     Testcase:                    
Architecture:  Unknown/Multiple                               |      Failure:  Compile-time crash
--------------------------------------------------------------+-------------
Changes (by igloo):

  * milestone:  => 6.12.2


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 05:50:56 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:24:20 2010
Subject: [GHC] #3803: addCoverageTicksTobind should not panic when file
 location is Nothing
In-Reply-To: <046.170aea52f7935907ca6deb8869a6f4be@abbot.galois.com>
References: <046.170aea52f7935907ca6deb8869a6f4be@abbot.galois.com>
Message-ID: <055.62d2d2a7f750c8eaa4ae2e210117d23b@abbot.galois.com>

#3803: addCoverageTicksTobind should not panic when file location is Nothing
---------------------------------+------------------------------------------
    Reporter:  clemens           |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  Compiler          |      Version:  6.12.1      
    Keywords:  hpc               |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3803#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 05:51:17 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:24:41 2010
Subject: [GHC] #3804: strange output of mkGHCConstants on SunOS 5.8/sparc
In-Reply-To: <042.aa6d3bd949f1a02a1e301e5062530c41@abbot.galois.com>
References: <042.aa6d3bd949f1a02a1e301e5062530c41@abbot.galois.com>
Message-ID: <051.a0c204cfb0911b9c39498fd6513a5772@abbot.galois.com>

#3804: strange output of mkGHCConstants on SunOS 5.8/sparc
-----------------------------+----------------------------------------------
    Reporter:  CBa           |        Owner:                     
        Type:  bug           |       Status:  new                
    Priority:  normal        |    Milestone:                     
   Component:  Build System  |      Version:  6.12.1             
    Keywords:                |   Difficulty:                     
          Os:  Solaris       |     Testcase:                     
Architecture:  sparc         |      Failure:  Building GHC failed
-----------------------------+----------------------------------------------
Description changed by igloo:

Old description:

> mkGHCConstants generates a file with:
>

>
> oFFSET_StgRegTable_rR1 :: Int[[BR]]
> oFFSET_StgRegTable_rR1 = zd[[BR]]
> oFFSET_StgRegTable_rR2 :: Int[[BR]]
> oFFSET_StgRegTable_rR2 = zd[[BR]]
> ...
>

>
> whatever zd is. My bootstrap-ghc is 6.8.3.

New description:

 mkGHCConstants generates a file with:

 {{{
 oFFSET_StgRegTable_rR1 :: Int[[BR]]
 oFFSET_StgRegTable_rR1 = zd[[BR]]
 oFFSET_StgRegTable_rR2 :: Int[[BR]]
 oFFSET_StgRegTable_rR2 = zd[[BR]]
 ...
 }}}

 whatever zd is. My bootstrap-ghc is 6.8.3.

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3804#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 05:51:33 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:24:57 2010
Subject: [GHC] #3804: strange output of mkGHCConstants on SunOS 5.8/sparc
In-Reply-To: <042.aa6d3bd949f1a02a1e301e5062530c41@abbot.galois.com>
References: <042.aa6d3bd949f1a02a1e301e5062530c41@abbot.galois.com>
Message-ID: <051.5f87e0b4182c28ff45f5ca3f7fd2aff4@abbot.galois.com>

#3804: strange output of mkGHCConstants on SunOS 5.8/sparc
-----------------------------+----------------------------------------------
    Reporter:  CBa           |        Owner:                     
        Type:  bug           |       Status:  new                
    Priority:  normal        |    Milestone:                     
   Component:  Build System  |      Version:  6.12.1             
    Keywords:                |   Difficulty:                     
          Os:  Solaris       |     Testcase:                     
Architecture:  sparc         |      Failure:  Building GHC failed
-----------------------------+----------------------------------------------
Description changed by igloo:

Old description:

> mkGHCConstants generates a file with:
>
> {{{
> oFFSET_StgRegTable_rR1 :: Int[[BR]]
> oFFSET_StgRegTable_rR1 = zd[[BR]]
> oFFSET_StgRegTable_rR2 :: Int[[BR]]
> oFFSET_StgRegTable_rR2 = zd[[BR]]
> ...
> }}}
>
> whatever zd is. My bootstrap-ghc is 6.8.3.

New description:

 mkGHCConstants generates a file with:

 {{{
 oFFSET_StgRegTable_rR1 :: Int
 oFFSET_StgRegTable_rR1 = zd
 oFFSET_StgRegTable_rR2 :: Int
 oFFSET_StgRegTable_rR2 = zd
 ...
 }}}

 whatever zd is. My bootstrap-ghc is 6.8.3.

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3804#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 05:54:24 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:27:49 2010
Subject: [GHC] #3804: strange output of mkGHCConstants on SunOS 5.8/sparc
In-Reply-To: <042.aa6d3bd949f1a02a1e301e5062530c41@abbot.galois.com>
References: <042.aa6d3bd949f1a02a1e301e5062530c41@abbot.galois.com>
Message-ID: <051.0cdfdc5bebc755ea91b4e5f771d1398a@abbot.galois.com>

#3804: strange output of mkGHCConstants on SunOS 5.8/sparc
-----------------------------+----------------------------------------------
    Reporter:  CBa           |        Owner:                     
        Type:  bug           |       Status:  new                
    Priority:  normal        |    Milestone:  6.12.2             
   Component:  Build System  |      Version:  6.12.1             
    Keywords:                |   Difficulty:                     
          Os:  Solaris       |     Testcase:                     
Architecture:  sparc         |      Failure:  Building GHC failed
-----------------------------+----------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


Comment:

 Thanks for the report.

 %zd is the format specifier for size_t ints; I'd guess that gcc on SunOS
 5.8 doesn't support it (although presumably newer versions do, as I think
 other people have successfully built GHC on newer versions.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3804#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 05:55:15 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:28:39 2010
Subject: [GHC] #3807: Test for correct shared library generation
In-Reply-To: <048.928719cb181f5e3e6b547832c856a384@abbot.galois.com>
References: <048.928719cb181f5e3e6b547832c856a384@abbot.galois.com>
Message-ID: <057.d0678959b4d64414b6afa14db404e0d2@abbot.galois.com>

#3807: Test for correct shared library generation
---------------------------------+------------------------------------------
    Reporter:  asuffield         |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  Test Suite        |      Version:  6.12.1      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  => 6.12.2


Comment:

 Thanks for the report.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3807#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 05:55:44 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:29:09 2010
Subject: [GHC] #3814: Compile to more than one (sub)-architecture
In-Reply-To: <045.81dca617e2084ce61e4f3745c003b436@abbot.galois.com>
References: <045.81dca617e2084ce61e4f3745c003b436@abbot.galois.com>
Message-ID: <054.bb705cbb131fc731392e6b8629b9ac84@abbot.galois.com>

#3814: Compile to more than one (sub)-architecture
-----------------------------------------------+----------------------------
    Reporter:  filcab                          |        Owner:              
        Type:  feature request                 |       Status:  new         
    Priority:  normal                          |    Milestone:              
   Component:  Compiler                        |      Version:  6.12.1      
    Keywords:  architecture, compiler, x86_64  |   Difficulty:              
          Os:  Unknown/Multiple                |     Testcase:              
Architecture:  Unknown/Multiple                |      Failure:  None/Unknown
-----------------------------------------------+----------------------------
Description changed by igloo:

Old description:

> GHC, as far as I can tell, can only compile files for one architecture
> (let's call it the "host architecture").
>
> This brings some problems... The biggest of which is that we lose the
> option of building for 32/64 bits in one of the "hybrid" architectures
> (For example, in x86_64-linux or i386-darwin)
>
> If I build a ghc in a x86_64 linux I will only get the x86_64 code
> generator and not the i386 generator. This will stop me from building a
> program which links with a library that only has a 32-bit version.
> If I want a GHC which will only compile for the i386, I will have to
> cross-compile, which is not very pretty.
>
> The same will happen on the Mac OS X side (even though the x86_64-darwin
> port is still on its way...).
>

> But GHC "should" (IMHO) be able to do like GCC and be able to generate
> code for both architecturess (i386 and x86_64), through the usage of
> compiler flags (which would also be passed to any gcc sub-process, if
> need be). At least if it is installed in a x86_64 (and PPC, if PPC64 is
> supported) system.
>

> Even better would be to do like LLVM's llc which enables a user to
> generate an assembly file for a target architecture from any other
> architecture.
>
> Example of an LLVM target list:
> filcab@fry:/stuff/src> llc --version
> Low Level Virtual Machine (http://llvm.org/):
>   llvm version 2.7svn
>   DEBUG build with assertions.
>   Built Jan 10 2010 (00:25:59).
>   Host: x86_64-unknown-linux-gnu
>   Host CPU: core2
>
>   Registered Targets:
>     arm     - ARM
>     c       - C backend
>     cellspu - STI CBEA Cell SPU [experimental]
>     cpp     - C++ backend
>     mips    - Mips
>     msil    - MSIL backend
>     ppc64   - PowerPC 64
>     sparc   - Sparc
>     x86     - 32-bit X86: Pentium-Pro and above
>     x86-64  - 64-bit X86: EM64T and AMD64

New description:

 GHC, as far as I can tell, can only compile files for one architecture
 (let's call it the "host architecture").

 This brings some problems... The biggest of which is that we lose the
 option of building for 32/64 bits in one of the "hybrid" architectures
 (For example, in x86_64-linux or i386-darwin)

 If I build a ghc in a x86_64 linux I will only get the x86_64 code
 generator and not the i386 generator. This will stop me from building a
 program which links with a library that only has a 32-bit version.
 If I want a GHC which will only compile for the i386, I will have to
 cross-compile, which is not very pretty.

 The same will happen on the Mac OS X side (even though the x86_64-darwin
 port is still on its way...).


 But GHC "should" (IMHO) be able to do like GCC and be able to generate
 code for both architecturess (i386 and x86_64), through the usage of
 compiler flags (which would also be passed to any gcc sub-process, if need
 be). At least if it is installed in a x86_64 (and PPC, if PPC64 is
 supported) system.


 Even better would be to do like LLVM's llc which enables a user to
 generate an assembly file for a target architecture from any other
 architecture.

 Example of an LLVM target list:
 {{{
 filcab@fry:/stuff/src> llc --version
 Low Level Virtual Machine (http://llvm.org/):
   llvm version 2.7svn
   DEBUG build with assertions.
   Built Jan 10 2010 (00:25:59).
   Host: x86_64-unknown-linux-gnu
   Host CPU: core2

   Registered Targets:
     arm     - ARM
     c       - C backend
     cellspu - STI CBEA Cell SPU [experimental]
     cpp     - C++ backend
     mips    - Mips
     msil    - MSIL backend
     ppc64   - PowerPC 64
     sparc   - Sparc
     x86     - 32-bit X86: Pentium-Pro and above
     x86-64  - 64-bit X86: EM64T and AMD64
 }}}

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3814#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 05:57:28 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:30:53 2010
Subject: [GHC] #3814: Compile to more than one (sub)-architecture
In-Reply-To: <045.81dca617e2084ce61e4f3745c003b436@abbot.galois.com>
References: <045.81dca617e2084ce61e4f3745c003b436@abbot.galois.com>
Message-ID: <054.2fa7ce33a1d84eefd7ba4dd275b0768a@abbot.galois.com>

#3814: Compile to more than one (sub)-architecture
-----------------------------------------------+----------------------------
    Reporter:  filcab                          |        Owner:              
        Type:  feature request                 |       Status:  new         
    Priority:  normal                          |    Milestone:  _|_         
   Component:  Compiler                        |      Version:  6.12.1      
    Keywords:  architecture, compiler, x86_64  |   Difficulty:              
          Os:  Unknown/Multiple                |     Testcase:              
Architecture:  Unknown/Multiple                |      Failure:  None/Unknown
-----------------------------------------------+----------------------------
Changes (by igloo):

  * milestone:  => _|_


Comment:

 This is something we're slowly working towards. See also #964.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3814#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 05:57:39 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:31:11 2010
Subject: [GHC] #964: Cross Compile and Universal Binary
In-Reply-To: <070.aac5ee31b362526bf71e8f397562d506@abbot.galois.com>
References: <070.aac5ee31b362526bf71e8f397562d506@abbot.galois.com>
Message-ID: <079.61b1d0ee325b8e416ee154bbc5be40d4@abbot.galois.com>

#964: Cross Compile and Universal Binary
------------------------------------------------+---------------------------
    Reporter:  shelarcy@?                       |        Owner:                            
        Type:  feature request                  |       Status:  new                       
    Priority:  normal                           |    Milestone:  _|_                       
   Component:  Compiler                         |      Version:  6.6                       
    Keywords:                                   |   Difficulty:  Project (more than a week)
          Os:  MacOS X                          |     Testcase:  N/A                       
Architecture:  Unknown/Multiple                 |      Failure:  None/Unknown              
------------------------------------------------+---------------------------
Changes (by igloo):

  * failure:  => None/Unknown


Comment:

 See also #3814.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/964#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 06:14:00 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 05:47:23 2010
Subject: [GHC] #3818: ghc-pkg prints warnings to stdout instead of stderr
Message-ID: <046.3fb054c38af92e36aa356532b619a97e@abbot.galois.com>

#3818: ghc-pkg prints warnings to stdout instead of stderr
---------------------------------+------------------------------------------
    Reporter:  nomeata           |       Owner:                
        Type:  bug               |      Status:  new           
    Priority:  normal            |   Component:  Package system
     Version:  6.12.1            |    Keywords:                
          Os:  Unknown/Multiple  |    Testcase:                
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown  
---------------------------------+------------------------------------------
 The warning
 {{{
 WARNING: cache is out of date:
 /var/lib/ghc-6.12.1/package.conf.d/package.cache
   use 'ghc-pkg recache' to fix.
 }}}
 is printed to stdout, which breaks scripts. It should be printed to stderr
 instead.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3818>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 09:35:08 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 09:08:34 2010
Subject: [GHC] #2452: Add a flag to disable the implicit qualified
 import of every available module in interactive mode
In-Reply-To: <049.31db7471187fa0b39e4d12923cd80edb@abbot.galois.com>
References: <049.31db7471187fa0b39e4d12923cd80edb@abbot.galois.com>
Message-ID: <058.47c34e4a6231b0a8bde885df609f76d3@abbot.galois.com>

#2452: Add a flag to disable the implicit qualified import of every available
module in interactive mode
--------------------------------------+-------------------------------------
  Reporter:  jcpetruzza               |          Owner:  simonmar        
      Type:  feature request          |         Status:  closed          
  Priority:  normal                   |      Milestone:  6.10.1          
 Component:  Compiler (Type checker)  |        Version:  6.9             
Resolution:  fixed                    |       Keywords:                  
Difficulty:  Unknown                  |             Os:  Unknown/Multiple
  Testcase:                           |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown             |  
--------------------------------------+-------------------------------------
Changes (by guest):

  * failure:  => None/Unknown


Comment:

 I assumed, that I could achieve the wanted behaviour with
 {{{
 ghci -hide-all-packages -package haskell98
 }}}
 in GHC-6.10.4, but it aborts with
 {{{
 GHCi, version 6.10.4: http://www.haskell.org/ghc/  :? for help
 Loading package ghc-prim ... linking ... done.
 Loading package integer ... linking ... done.
 Loading package base ... linking ... done.
 Loading package syb ... linking ... done.
 Loading package array-0.2.0.0 ... linking ... done.
 Loading package filepath-1.1.0.2 ... linking ... done.
 Loading package old-locale-1.0.0.1 ... linking ... done.
 Loading package old-time-1.0.0.2 ... linking ... done.
 Loading package unix-2.3.2.0 ... linking ... done.
 Loading package directory-1.0.0.3 ... linking ... done.
 Loading package process-1.0.1.1 ... linking ... done.
 Loading package random-1.0.0.1 ... linking ... done.
 Loading package haskell98 ... linking ... done.
 <command line>: Could not find module `Prelude':
   it is a member of the hidden package `base-3.0.3.1'
   it is a member of the hidden package `base'
   Use -v to see a list of the files searched for.
 }}}

 For my taste, the Unsafe modules should go to an extra package anyway.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2452#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 12:41:32 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 12:14:58 2010
Subject: [GHC] #3808: piping  binary files sometimes fail
In-Reply-To: <046.03975d9a46f4033a58b89642ef5736ae@abbot.galois.com>
References: <046.03975d9a46f4033a58b89642ef5736ae@abbot.galois.com>
Message-ID: <055.15cce8ee9b450ecfecb29da13cfae582@abbot.galois.com>

#3808: piping  binary files sometimes fail
-------------------------------+--------------------------------------------
    Reporter:  paolino         |        Owner:  simonmar     
        Type:  bug             |       Status:  assigned     
    Priority:  high            |    Milestone:  6.12.2       
   Component:  Compiler        |      Version:  6.12.1       
    Keywords:  pipe binary IO  |   Difficulty:               
          Os:  Linux           |     Testcase:               
Architecture:  x86_64 (amd64)  |      Failure:  Runtime crash
-------------------------------+--------------------------------------------

Comment(by paolino):

 Replying to [comment:3 simonmar]:
 > `Data.ByteString.Lazy.hGetContents` calls `hIsEOF` which calls
 `hLookAhead`, and `hLookAhead` reads the next `Char` from the `Handle`,
 which does Unicode decoding. Putting `stdin` into binary mode fixes the
 problem.
 >
 In the program revealing the error, putting stdin in binary mode was not
 fixing. It is my fault that I coldn't reproduce that behaviour in the
 given example, which indeed is fixed by this setting.
 > After giving this a bit of thought, I think the best solution is to make
 `hIsEOF` not do any decoding, so I'll look into doing that.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3808#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 12:57:50 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 12:31:14 2010
Subject: [GHC] #3729: Allow modification of capabilities at runtime
In-Reply-To: <047.1fc6c652629dc9260c76c16a8c0a5af6@abbot.galois.com>
References: <047.1fc6c652629dc9260c76c16a8c0a5af6@abbot.galois.com>
Message-ID: <056.bae3587bfb118a128f9d9f8949a89a68@abbot.galois.com>

#3729: Allow modification of capabilities at runtime
---------------------------------+------------------------------------------
    Reporter:  mlesniak          |        Owner:              
        Type:  task              |       Status:  new         
    Priority:  normal            |    Milestone:  6.14 branch 
   Component:  Runtime System    |      Version:  6.13        
    Keywords:  capabilities      |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by NeilMitchell):

 * cc: ndmitchell@? (added)


Comment:

 This would be great so applications can implement {{{-j3}}} flags
 internally, rather than relying on the user to write {{{+RTS -N3 -RTS}}}.
 The original requester seems to be thinking of developers, but this
 feature would be a massive benefit to end users of Haskell programmers.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3729#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 13:19:03 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 12:52:27 2010
Subject: [GHC] #3773: Haddoc documentation on wrong function argument
In-Reply-To: <044.635ed03af9d418169b269fce9db0718f@abbot.galois.com>
References: <044.635ed03af9d418169b269fce9db0718f@abbot.galois.com>
Message-ID: <053.d2a7ec9c9a44a5473ff75ee5511a7879@abbot.galois.com>

#3773: Haddoc documentation on wrong function argument
---------------------------------+------------------------------------------
    Reporter:  tibbe             |        Owner:  isaacdupree 
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  Documentation     |      Version:  6.10.4      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by isaacdupree):

 * cc: id@? (added)
  * owner:  waern => isaacdupree


Comment:

 i'm chasing this

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3773#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 14:17:44 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 13:51:11 2010
Subject: [GHC] #3773: Haddoc documentation on wrong function argument
In-Reply-To: <044.635ed03af9d418169b269fce9db0718f@abbot.galois.com>
References: <044.635ed03af9d418169b269fce9db0718f@abbot.galois.com>
Message-ID: <053.98134bc9d029d40e5aebd02144aeddc6@abbot.galois.com>

#3773: Haddoc documentation on wrong function argument
---------------------------------+------------------------------------------
    Reporter:  tibbe             |        Owner:  waern       
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  Documentation     |      Version:  6.10.4      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by isaacdupree):

  * owner:  isaacdupree => waern


Comment:

 ok, I found the bugs in that haddock code; here's the patch. (linked since
 trac refused my attachment). Please test it...and amend/apply as
 appropriate (since my system upgrade/reinstall, it wasn't even easy for me
 to compile haddock successfully so I didn't yet)

 http://isaac.cedarswampstudios.org/2010a/isaacsHopefullyAHtmlBugfix.dpatch

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3773#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 14:33:50 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 14:07:15 2010
Subject: [GHC] #3736: GHC specialising instead of inlining
In-Reply-To: <044.6187e75fed543439fb0c0aaede8523f0@abbot.galois.com>
References: <044.6187e75fed543439fb0c0aaede8523f0@abbot.galois.com>
Message-ID: <053.f7e1dc12fbb3fe3af04f69fe54367f34@abbot.galois.com>

#3736: GHC specialising instead of inlining
--------------------------------------+-------------------------------------
  Reporter:  guest                    |          Owner:          
      Type:  bug                      |         Status:  new     
  Priority:  normal                   |      Component:  Compiler
   Version:  6.10.4                   |       Keywords:          
Difficulty:                           |             Os:  Linux   
  Testcase:                           |   Architecture:  x86     
   Failure:  Runtime performance bug  |  
--------------------------------------+-------------------------------------

Comment(by guest):

 I uploaded a package that should be self-contained:
 http://code.haskell.org/storablevector/ghc-profile/dist/storablevector-
 profile-0.2.tar.gz

 The run-time didn't change in any of the examples from GHC-6.10.4 to
 GHC-6.12.1. That made me uncertain, but I double checked that I actually
 used GHC-6.12.1 in the newer tests.

 (Trac did not let me add this archive as attachment, thus I have uploaded
 it to code.haskell.org)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3736#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 15:18:34 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 14:51:57 2010
Subject: [GHC] #3819: keeping RelaxedPolyRec as optional feature can help
 spotting infinite recursion
Message-ID: <044.0e1c1bc29d90c282db7fbdce5eea65b6@abbot.galois.com>

#3819: keeping RelaxedPolyRec as optional feature can help spotting infinite
recursion
---------------------------------+------------------------------------------
    Reporter:  guest             |       Owner:                         
        Type:  proposal          |      Status:  new                    
    Priority:  normal            |   Component:  Compiler (Type checker)
     Version:  6.12.1            |    Keywords:                         
          Os:  Unknown/Multiple  |    Testcase:                         
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown           
---------------------------------+------------------------------------------
 This is a ticket you have nothing to do about - isn't this great?
 I just want to give a real-world case where the current behaviour helped
 me to detect an infinite recursion early.

 I wrote the following code, that implements a {{{poke}}} for any
 {{{Traversable}}} container with {{{Storable}}} elements:
 {{{
    poke ::
       (Fold.Foldable f, Storable a) =>
       Ptr (f a) -> f a -> IO ()
    poke ptr x =
       evalStateT (Fold.traverse_ pokeState x) $
       castPtr ptr

    pokeState ::
       (Storable a) =>
       a -> StateT (Ptr a) IO ()
    pokeState x = do
       liftIO . flip poke x =<< get
       modify (flip advancePtr 1)
 }}}

 You can find this code here:
   http://code.haskell.org/~thielema/storable-
 record/src/Foreign/Storable/Traversable.hs

 When I compiled this I got the compiler error:
 {{{
    src/Foreign/Storable/Traversable.hs:67:0:
        Contexts differ in length
          (Use -XRelaxedPolyRec to allow this)
        When matching the contexts of the signatures for
          poke :: forall (f :: * -> *) a.
                  (Fold.Foldable f, Storable a) =>
                  Ptr (f a) -> f a -> IO ()
          pokeState :: forall a. (Storable a) => a -> StateT (Ptr a) IO ()
        The signature contexts in a mutually recursive group should all be
 identical
        When generalising the type(s) for poke, pokeState
 }}}
 This quickly pointed me to the problem, that the call to {{{poke}}} in
 {{{pokeState}}} actually was wrong. It must be {{{Storable.poke}}}. If GHC
 had compiled this, it would have certainly gone into an infinite
 recursion.

 There are two ways to treat this example:
 * Blame my naming style where I re-use common identifiers and distinguish
 them later by qualification.
 * Count it as vote for keeping the RelaxedPolyRec as optional feature.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3819>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 15:22:25 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 14:55:48 2010
Subject: [GHC] #3819: keeping RelaxedPolyRec as optional feature can
 help spotting infinite recursion
In-Reply-To: <044.0e1c1bc29d90c282db7fbdce5eea65b6@abbot.galois.com>
References: <044.0e1c1bc29d90c282db7fbdce5eea65b6@abbot.galois.com>
Message-ID: <053.7af092fd73f88de1f3bb8952be7a0800@abbot.galois.com>

#3819: keeping RelaxedPolyRec as optional feature can help spotting infinite
recursion
-------------------------+--------------------------------------------------
Reporter:  guest         |          Owner:                         
    Type:  proposal      |         Status:  closed                 
Priority:  normal        |      Component:  Compiler (Type checker)
 Version:  6.12.1        |     Resolution:  fixed                  
Keywords:                |             Os:  Unknown/Multiple       
Testcase:                |   Architecture:  Unknown/Multiple       
 Failure:  None/Unknown  |  
-------------------------+--------------------------------------------------
Changes (by guest):

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


Comment:

 However ... when I enable RelaxedPolyRec, the error is catched
 nevertheless:
 {{{
     Couldn't match expected type `f a' against inferred type `a1'
     ...
 }}}
 I should change the proposal to "keep Haskell statically typed". :-)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3819#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 16:28:14 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 16:01:43 2010
Subject: [GHC] #3729: Allow modification of capabilities at runtime
In-Reply-To: <047.1fc6c652629dc9260c76c16a8c0a5af6@abbot.galois.com>
References: <047.1fc6c652629dc9260c76c16a8c0a5af6@abbot.galois.com>
Message-ID: <056.878065af8ba48700f923aeab4491a91e@abbot.galois.com>

#3729: Allow modification of capabilities at runtime
---------------------------------+------------------------------------------
    Reporter:  mlesniak          |        Owner:              
        Type:  task              |       Status:  new         
    Priority:  normal            |    Milestone:  6.14 branch 
   Component:  Runtime System    |      Version:  6.13        
    Keywords:  capabilities      |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by mlesniak):

 As you can see [http://www.mlesniak.com/category/capabilities/ here], I'm
 currently "trying" to implement this. Since I'm quite new to GHC's
 development I'm a bit lost but fiddling my way around in my free time.

 I'd be grateful to any pointers, links to documentation or blog post,
 etc...

 - Michael

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3729#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 16:48:37 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 16:22:01 2010
Subject: [GHC] #3820: Pragma for suppressing 'orphan instance' warnings per
 instance
Message-ID: <044.744018ec3a95e53b8f2d7e0ead54e910@abbot.galois.com>

#3820: Pragma for suppressing 'orphan instance' warnings per instance
---------------------------------+------------------------------------------
    Reporter:  guest             |       Owner:                         
        Type:  feature request   |      Status:  new                    
    Priority:  normal            |   Component:  Compiler (Type checker)
     Version:  6.12.1            |    Keywords:                         
          Os:  Unknown/Multiple  |    Testcase:                         
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown           
---------------------------------+------------------------------------------
 Additionally to #2515 I'd like to suppress orphan instances warnings
 individually. I do not always like to disable orphan instance warnings
 globally for a module, since some of the warnings may point to an instance
 that can actually be moved to a more appropriate module.

 Syntax could be
 {{{
 {-# NOWARN orphan #-}
 instance C T where
    ...
 }}}
 or simply
 {{{
 {-# NOWARN #-}
 instance C T where
    ...
 }}}

 (Before GHC-6.12 a general local NOWARN pragma could also help to minimize
 wrong warnings about unused imported modules. And sometimes I also like to
 disable 'unused identifier' warning for some top-level functions, that
 shall be type checked, but not exported, because their API is still not
 mature.)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3820>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 14 18:03:36 2010
From: trac at galois.com (GHC)
Date: Thu Jan 14 17:37:01 2010
Subject: [GHC] #3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when
 loading module
In-Reply-To: <044.c8fe00d0df86676aef8470e80da77abf@abbot.galois.com>
References: <044.c8fe00d0df86676aef8470e80da77abf@abbot.galois.com>
Message-ID: <053.a7879fbea9fd807d69366c299ad716bd@abbot.galois.com>

#3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when loading module
----------------------+-----------------------------------------------------
  Reporter:  fasta    |          Owner:                  
      Type:  bug      |         Status:  closed          
  Priority:  normal   |      Milestone:                  
 Component:  GHCi     |        Version:  6.10.4          
Resolution:  wontfix  |       Keywords:                  
Difficulty:           |             Os:  Unknown/Multiple
  Testcase:           |   Architecture:  Unknown/Multiple
   Failure:  Other    |  
----------------------+-----------------------------------------------------

Comment(by simonmar):

 There is "worksforme", which I think is intended for cases like that.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3720#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 03:40:00 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 03:13:23 2010
Subject: [GHC] #3820: Pragma for suppressing 'orphan instance' warnings
 per instance
In-Reply-To: <044.744018ec3a95e53b8f2d7e0ead54e910@abbot.galois.com>
References: <044.744018ec3a95e53b8f2d7e0ead54e910@abbot.galois.com>
Message-ID: <053.431ba9f32e59dbe06d2d5ae061025a3a@abbot.galois.com>

#3820: Pragma for suppressing 'orphan instance' warnings per instance
----------------------------------------+-----------------------------------
    Reporter:  guest                    |        Owner:              
        Type:  feature request          |       Status:  new         
    Priority:  normal                   |    Milestone:              
   Component:  Compiler (Type checker)  |      Version:  6.12.1      
    Keywords:                           |   Difficulty:              
          Os:  Unknown/Multiple         |     Testcase:              
Architecture:  Unknown/Multiple         |      Failure:  None/Unknown
----------------------------------------+-----------------------------------

Comment(by simonpj):

 Reasonable request.  I'd be happy to advise anyone who wanted to implement
 it.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3820#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 05:31:41 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 05:05:05 2010
Subject: [GHC] #3821: Trace.Hpc.Reflect.examineTix segfaults on 64bit
Message-ID: <053.fbf59e92eb99357652de0927fec4376a@abbot.galois.com>

#3821: Trace.Hpc.Reflect.examineTix segfaults on 64bit
---------------------------------+------------------------------------------
    Reporter:  TristanAllwood    |       Owner:  andy@?         
        Type:  bug               |      Status:  new            
    Priority:  normal            |   Component:  Code Coverage  
     Version:  6.12.1            |    Keywords:                 
          Os:  Unknown/Multiple  |    Testcase:                 
Architecture:  x86_64 (amd64)    |     Failure:  None/Unknown   
---------------------------------+------------------------------------------
 The following seg-faults on my 64bit ghc 6.12.1 when compiled with
 {{{-fhpc}}}

 {{{
 module Main where

 import B
 import Trace.Hpc.Reflect

 main :: IO ()
 main = do
   examineTix
   print (foo 3)
   return ()
 }}}

 {{{
 module B where

 foo 0 = 0
 foo n = 1 + foo (n-1)
 }}}


 {{{
 >ghc --make -fforce-recomp -fhpc Main
 [1 of 2] Compiling B                ( B.hs, B.o )
 [2 of 2] Compiling Main             ( Main.hs, Main.o )
 Linking Main ...

 10:21:55 - tora@colorado:/tmp/HPC
 >./Main
 Segmentation fault
 }}}


 I believe the cause is that
 {{{ data ModuleInfo = ModuleInfo String Int Hash (Ptr Word64) }}}
 in {{{Trace.Hpc.Reflect}}} uses a variable sized {{{Int}}} instead of a
 fixed (32bit if I'm reading the sources correctly) Word32 for the count.

 I've attached a patch that should fix the issue.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3821>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 05:37:12 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 05:10:35 2010
Subject: [GHC] #3821: Trace.Hpc.Reflect.examineTix segfaults on 64bit
In-Reply-To: <053.fbf59e92eb99357652de0927fec4376a@abbot.galois.com>
References: <053.fbf59e92eb99357652de0927fec4376a@abbot.galois.com>
Message-ID: <062.f49cd250ee1e09372b8eecaa93f657d9@abbot.galois.com>

#3821: Trace.Hpc.Reflect.examineTix segfaults on 64bit
---------------------------------+------------------------------------------
    Reporter:  TristanAllwood    |       Owner:  andy@?         
        Type:  bug               |      Status:  new            
    Priority:  normal            |   Component:  Code Coverage  
     Version:  6.12.1            |    Keywords:                 
          Os:  Unknown/Multiple  |    Testcase:                 
Architecture:  x86_64 (amd64)    |     Failure:  None/Unknown   
---------------------------------+------------------------------------------

Comment(by TristanAllwood):

 Trac is failing to let me add the patch file - it's smallish so here it is
 inline...

 {{{
 Fri Jan 15 10:21:41 GMT 2010  tora@zonetora.co.uk
   * Use a fixed size value when reading from Memory for ModuleInfo's

 New patches:

 [Use a fixed size value when reading from Memory for ModuleInfo's
 tora@zonetora.co.uk**20100115102141
  Ignore-this: a7cef3dacbb29c22a12f654c616f500e
 ] {
 hunk ./Trace/Hpc/Reflect.hsc 43
        ptr <- hs_hpc_rootModule
        moduleInfoList ptr

 -data ModuleInfo = ModuleInfo String Int Hash (Ptr Word64)
 +data ModuleInfo = ModuleInfo String Word32 Hash (Ptr Word64)

  moduleInfoList :: Ptr () -> IO [ModuleInfo]
  moduleInfoList ptr
 hunk ./Trace/Hpc/Reflect.hsc 60

  clearTix :: IO ()
  clearTix = do
 -      sequence_ [ pokeArray ptr $ take count $ repeat 0
 +      sequence_ [ pokeArray ptr $ take (fromIntegral count) $ repeat 0
                 | ModuleInfo _mod count _hash ptr <- modInfo
                 ]
        return ()
 hunk ./Trace/Hpc/Reflect.hsc 68

  examineTix :: IO Tix
  examineTix = do
 -      mods <- sequence [ do tixs <- peekArray count ptr
 -                           return $ TixModule mod' hash count
 +      mods <- sequence [ do tixs <- peekArray (fromIntegral count) ptr
 +                           return $ TixModule mod' hash (fromIntegral
 count)
                                    $ map fromIntegral tixs
                        | (ModuleInfo mod' count hash ptr) <- modInfo
                        ]
 hunk ./Trace/Hpc/Reflect.hsc 85
                 | (ModuleInfo mod1 count1 hash1 ptr,
                    TixModule mod2 hash2 count2 tixs) <- zip modInfo
 modTixes
                 , if mod1 /= mod2
 -               || count1 /= count2
 +               || (fromIntegral count1) /= count2
                 || hash1 /= hash2
                 || length tixs /= count2
                   then error "updateTix failed"
 }

 Context:

 [Fix quoting in the "tough" test
 Ian Lynagh <igloo@earth.li>**20100102174643]
 [Fix quoting in more tests
 Ian Lynagh <igloo@earth.li>**20100102174616]
 [Fix quoting in some hpc tests
 Ian Lynagh <igloo@earth.li>**20100102174221]
 [Fix tests/hpcrun.pl to handle paths containing spaces
 Ian Lynagh <igloo@earth.li>**20100102173344]
 [Bump version number
 Ian Lynagh <igloo@earth.li>**20091219201528]
 [Remove unused test bits
 Ian Lynagh <igloo@earth.li>**20091219195119]
 [Fix some more hpc tests
 Ian Lynagh <igloo@earth.li>**20091219194957]
 [Fix some hpc tests
 Ian Lynagh <igloo@earth.li>**20091219192808]
 [Comment that we need to fix cleaning the tests
 Ian Lynagh <igloo@earth.li>**20091219164941]
 [Tweak some hpc tests
 Ian Lynagh <igloo@earth.li>**20091215215405]
 [Fix some quoting problems in the tests
 Ian Lynagh <igloo@earth.li>**20091209194903]
 [Whitespace only
 Ian Lynagh <igloo@earth.li>**20091203134407]
 [Follow testsuite driver changes
 Ian Lynagh <igloo@earth.li>**20091128185017]
 [Update dependencies
 Ian Lynagh <igloo@earth.li>**20090920152421]
 [Bump version to 0.5.0.4
 Ian Lynagh <igloo@earth.li>**20090920141921]
 [Fix unused import warnings
 Ian Lynagh <igloo@earth.li>**20090707133640]
 [Remove unused imports
 Ian Lynagh <igloo@earth.li>**20090707115847]
 [TAG 2009-06-25
 Ian Lynagh <igloo@earth.li>**20090625160250]
 Patch bundle hash:
 20b3a7d510206226e00ce3f8653484ba563f51ab
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3821#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 06:39:44 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 06:13:47 2010
Subject: [GHC] #3822: pattern guards in arrow notation (Arrows extension)
 case statement cause compiler panic
Message-ID: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com>

#3822: pattern guards in arrow notation (Arrows extension) case statement cause
compiler panic
----------------------------------+-----------------------------------------
    Reporter:  StephenBlackheath  |       Owner:                                  
        Type:  bug                |      Status:  new                             
    Priority:  normal             |   Component:  Compiler                        
     Version:  6.12.1             |    Keywords:  arrows pattern guards case panic
          Os:  Linux              |    Testcase:  patternGuard.hs                 
Architecture:  x86_64 (amd64)     |     Failure:  Compile-time crash              
----------------------------------+-----------------------------------------
 The attached test case causes this panic message:

 -----
 ghc: panic! (the 'impossible' happened)
   (GHC version 6.12.1 for x86_64-unknown-linux):
         initC: srt_lbl

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
 -----

 The offending line is the one with '| neg'.  It doesn't panic if you use
 the commented out line below it instead.

 This kind of case statement is specific to arrow notation (provided by the
 Arrows extension) - the compiler uses ArrowChoice to implement it.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3822>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 06:42:55 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 06:17:44 2010
Subject: [GHC] #3822: pattern guards in arrow notation (Arrows
 extension) case statement cause compiler panic
In-Reply-To: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com>
References: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com>
Message-ID: <065.71c807b786d69c5b91b95a3930b48066@abbot.galois.com>

#3822: pattern guards in arrow notation (Arrows extension) case statement cause
compiler panic
----------------------------------+-----------------------------------------
    Reporter:  StephenBlackheath  |       Owner:                                  
        Type:  bug                |      Status:  new                             
    Priority:  normal             |   Component:  Compiler                        
     Version:  6.12.1             |    Keywords:  arrows pattern guards case panic
          Os:  Linux              |    Testcase:  patternGuard.hs                 
Architecture:  x86_64 (amd64)     |     Failure:  Compile-time crash              
----------------------------------+-----------------------------------------

Comment(by StephenBlackheath):

 Trac won't let me attach files (OSError: [Errno 13] Permission denied:
 '/srv/trac/ghc/attachments/ticket/3822'), so here's the test case in a
 comment. Command line is
   ghc patternGuard.hs --make

 -------------------------------------------------
 {-# LANGUAGE Arrows #-}

 import Control.Arrow
 import qualified Control.Category as Cat

 test :: Int -> Int
 test = proc x -> do
     let neg = x < 0
     case x of
         x | neg -> returnA -< 0           -- GHC panics
         --x | x < 0 -> returnA -< 0       -- GHC doesn't panic
         _       -> returnA -< 10

 main = do
     print $ test (-1)
     print $ test 1

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3822#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 06:43:50 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 06:18:00 2010
Subject: [GHC] #3822: pattern guards in arrow notation (Arrows
 extension) case statement cause compiler panic
In-Reply-To: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com>
References: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com>
Message-ID: <065.cb71cf57fcce62c6574a4dcf4f260cc4@abbot.galois.com>

#3822: pattern guards in arrow notation (Arrows extension) case statement cause
compiler panic
----------------------------------+-----------------------------------------
    Reporter:  StephenBlackheath  |       Owner:                                  
        Type:  bug                |      Status:  new                             
    Priority:  normal             |   Component:  Compiler                        
     Version:  6.12.1             |    Keywords:  arrows pattern guards case panic
          Os:  Linux              |    Testcase:  patternGuard.hs                 
Architecture:  x86_64 (amd64)     |     Failure:  Compile-time crash              
----------------------------------+-----------------------------------------

Comment(by StephenBlackheath):

 {{{
 {-# LANGUAGE Arrows #-}

 import Control.Arrow
 import qualified Control.Category as Cat

 test :: Int -> Int
 test = proc x -> do
     let neg = x < 0
     case x of
         x | neg -> returnA -< 0           -- GHC panics
         --x | x < 0 -> returnA -< 0       -- GHC doesn't panic
         _       -> returnA -< 10

 main = do
     print $ test (-1)
     print $ test 1
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3822#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 07:04:33 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 06:38:12 2010
Subject: [GHC] #3822: pattern guards in arrow notation (Arrows
 extension) case statement cause compiler panic
In-Reply-To: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com>
References: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com>
Message-ID: <065.f30be4dad1e7b9821ad1fa4f492f39d8@abbot.galois.com>

#3822: pattern guards in arrow notation (Arrows extension) case statement cause
compiler panic
----------------------------------+-----------------------------------------
    Reporter:  StephenBlackheath  |       Owner:  ross                            
        Type:  bug                |      Status:  new                             
    Priority:  normal             |   Component:  Compiler                        
     Version:  6.12.1             |    Keywords:  arrows pattern guards case panic
          Os:  Linux              |    Testcase:  patternGuard.hs                 
Architecture:  x86_64 (amd64)     |     Failure:  Compile-time crash              
----------------------------------+-----------------------------------------
Changes (by ross):

  * owner:  => ross


Comment:

 Lovely report.  (This is an ordinary guard, rather than a pattern guard.)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3822#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 07:11:26 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 06:44:53 2010
Subject: [GHC] #3822: guards in arrow notation (Arrows extension) case
 statement cause compiler panic (was: pattern guards in arrow
 notation (Arrows extension) case statement cause compiler panic)
In-Reply-To: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com>
References: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com>
Message-ID: <065.3a6f3e18281d7bf39aeb3d5f5445f827@abbot.galois.com>

#3822: guards in arrow notation (Arrows extension) case statement cause compiler
panic
----------------------------------+-----------------------------------------
    Reporter:  StephenBlackheath  |       Owner:  ross                    
        Type:  bug                |      Status:  new                     
    Priority:  normal             |   Component:  Compiler                
     Version:  6.12.1             |    Keywords:  arrows guards case panic
          Os:  Unknown/Multiple   |    Testcase:  patternGuard.hs         
Architecture:  Unknown/Multiple   |     Failure:  Compile-time crash      
----------------------------------+-----------------------------------------
Changes (by ross):

  * keywords:  arrows pattern guards case panic => arrows guards case panic
  * os:  Linux => Unknown/Multiple
  * architecture:  x86_64 (amd64) => Unknown/Multiple


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3822#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 08:15:08 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 07:48:32 2010
Subject: [GHC] #3823: test
Message-ID: <044.391d2b508ffc80ff42ba596b1c8867b9@abbot.galois.com>

#3823: test
---------------------------------+------------------------------------------
    Reporter:  igloo             |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:              
   Component:  Compiler          |      Version:  6.12.1      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
 test

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3823>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 12:03:52 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 11:37:15 2010
Subject: [GHC] #3441: readProcess ... (exit 11): failed
In-Reply-To: <045.8b36c40db2200ba55ce3ac655baf5782@abbot.galois.com>
References: <045.8b36c40db2200ba55ce3ac655baf5782@abbot.galois.com>
Message-ID: <054.fd882dd295170ece0d2e5c78307d4cf5@abbot.galois.com>

#3441: readProcess ... (exit 11): failed
--------------------------------+-------------------------------------------
  Reporter:  Andriy             |          Owner:  simonmar           
      Type:  bug                |         Status:  closed             
  Priority:  normal             |      Milestone:  6.12.2             
 Component:  libraries/process  |        Version:  6.10.3             
Resolution:  worksforme         |       Keywords:  readProcess exit 11
Difficulty:  Unknown            |             Os:  Linux              
  Testcase:                     |   Architecture:  x86                
   Failure:  None/Unknown       |  
--------------------------------+-------------------------------------------
Changes (by simonmar):

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


Comment:

 Thanks for the core dump. Unfortunately I wasn't able to get any clues
 from it - it seems to correspond to a GHC binary different from the stock
 6.10.3 x86/Linux binary. I think at this point the only reasonable thing
 we can do is close this bug and hope the symptom re-appears under more
 reproducible conditions.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3441#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 17:07:22 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 16:39:50 2010
Subject: [GHC] #3745: Non-deterministic behavior with FFI
In-Reply-To: <048.13932c70c5ac7d2182ef99747868ffe2@abbot.galois.com>
References: <048.13932c70c5ac7d2182ef99747868ffe2@abbot.galois.com>
Message-ID: <057.8cf4716a9dd39d913881847e0249a9e2@abbot.galois.com>

#3745: Non-deterministic behavior with FFI
---------------------------------+------------------------------------------
    Reporter:  gchrupala         |        Owner:                             
        Type:  bug               |       Status:  new                        
    Priority:  high              |    Milestone:  6.12.2                     
   Component:  Compiler (FFI)    |      Version:  6.10.4                     
    Keywords:                    |   Difficulty:                             
          Os:  Unknown/Multiple  |     Testcase:                             
Architecture:  Unknown/Multiple  |      Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------

Comment(by simonmar):

 I can't reproduce it here on my laptop (x86/Linux).  Some questions:

  * can you make it happen on more than one machine? what platform(s)?
  * do you get different results when the program is compiled with
 `-debug`?
  * does valgrind say anything?
  * does it happen with 6.12.1?

 Is it possible there's a memory error in the FFI code, or the C++ code?
 perhaps an off-by-one array size?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3745#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 18:00:44 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 17:33:11 2010
Subject: [GHC] #3823: GHC 6.12 breaks combination of records and mutually
 recursive modules
Message-ID: <044.7cc1ab77124bd237b37d840aa7398830@abbot.galois.com>

#3823: GHC 6.12 breaks combination of records and mutually recursive modules
---------------------------------+------------------------------------------
    Reporter:  mboes             |       Owner:                           
        Type:  bug               |      Status:  new                      
    Priority:  normal            |   Component:  Compiler                 
     Version:  6.12.1            |    Keywords:                           
          Os:  Unknown/Multiple  |    Testcase:                           
Architecture:  Unknown/Multiple  |     Failure:  GHC rejects valid program
---------------------------------+------------------------------------------
 Take the following code for two mutually recursive modules A and B:
 {{{
 module A where

 import B

 data A = X { x :: Bool } | Y

 y :: A -> A
 y = \_ -> Y

 -- A.hs-boot
 module A where

 data A = X { x :: Bool } | Y

 y :: A -> A

 module B where

 import {-# SOURCE #-} A

 data B = A A

 a = x (X True)
 b = y a
 }}}
 Compiling this code with ghc --make or ghci gives:
 {{{
 [1 of 3] Compiling A[boot]          ( A.hs-boot, A.o-boot )
 [2 of 3] Compiling B                ( B.hs, B.o )

 B.hs:7:4:
     Can't find interface-file declaration for variable x
       Probable cause: bug in .hi-boot file, or inconsistent .hi file
       Use -ddump-if-trace to get an idea of which file caused the error
     In the expression: x (X True)
     In the definition of `a': a = x (X True)
 }}}
 This code used to work in GHC 6.10.

 Note that this issue breaks the build of the hmk package on Hackage.
 Doubtless other packages making use of mutually recursive modules hit this
 snag too.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3823>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 19:40:35 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 19:13:15 2010
Subject: [GHC] #3746: Poor parse error
In-Reply-To: <051.30594b4d5bf93a82dda06cabe9760a79@abbot.galois.com>
References: <051.30594b4d5bf93a82dda06cabe9760a79@abbot.galois.com>
Message-ID: <060.dc24d98b8e3e4c44ece5364db9376b20@abbot.galois.com>

#3746: Poor parse error
---------------------------------+------------------------------------------
    Reporter:  NeilMitchell      |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  6.14 branch 
   Component:  Compiler          |      Version:  6.10.4      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by heatsink):

 Other error-span-related tickets: #999, #984.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3746#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 19:46:18 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 19:18:57 2010
Subject: [GHC] #3333: GHCi doesn't load weak symbols
In-Reply-To: <047.f7df20b3080234226b9f5744151738a8@abbot.galois.com>
References: <047.f7df20b3080234226b9f5744151738a8@abbot.galois.com>
Message-ID: <056.17ef4289ae2a8b454d8cf4d6f1a0be36@abbot.galois.com>

#3333: GHCi doesn't load weak symbols
--------------------------------------+-------------------------------------
    Reporter:  heatsink               |        Owner:              
        Type:  bug                    |       Status:  new         
    Priority:  normal                 |    Milestone:  6.14.1      
   Component:  GHCi                   |      Version:  6.10.4      
    Keywords:  weak, dynamic loading  |   Difficulty:  Unknown     
          Os:  Linux                  |     Testcase:              
Architecture:  x86                    |      Failure:  None/Unknown
--------------------------------------+-------------------------------------
Description changed by heatsink:

Old description:

> GHCi fails to load modules with weak symbols.  The compiler, in contrast,
> has no trouble with them.  The attached Cabal package demonstrates the
> problem.  After building and installing:
>
> {{{
> :Prelude> :m +WeakTest
> Prelude WeakTest> weak_test 0
> Loading package WeakTest-0 ... linking ... <interactive>:
> /home/cirodrig/.cabal/lib/WeakTest-0/ghc-6.10.3/HSWeakTest-0.o: unknown
> symbol `weak_test'
> }}}
>
> I encountered this problem while trying to build a package that contains
> C++ code.  Because GCC generates weak symbols when compiling C++,
> libraries that contain C++ code will not work in GHCi.  (Granted, this is
> not the only problem with mixing C++ and Haskell.)

New description:

 GHCi fails to load modules with weak symbols.  The compiler, in contrast,
 has no trouble with them.  The attached Cabal package demonstrates the
 problem.  After building and installing:

 {{{
 :Prelude> :m +WeakTest
 Prelude WeakTest> weak_test 0
 Loading package WeakTest-0 ... linking ... <interactive>:
 /home/heatsink/.cabal/lib/WeakTest-0/ghc-6.10.3/HSWeakTest-0.o: unknown
 symbol `weak_test'
 }}}

 I encountered this problem while trying to build a package that contains
 C++ code.  Because GCC generates weak symbols when compiling C++,
 libraries that contain C++ code will not work in GHCi.  (Granted, this is
 not the only problem with mixing C++ and Haskell.)

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3333#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 15 21:50:46 2010
From: trac at galois.com (GHC)
Date: Fri Jan 15 21:23:24 2010
Subject: [GHC] #3333: GHCi doesn't load weak symbols
In-Reply-To: <047.f7df20b3080234226b9f5744151738a8@abbot.galois.com>
References: <047.f7df20b3080234226b9f5744151738a8@abbot.galois.com>
Message-ID: <056.43a7d46ea769fec1a78b8a7a7ff5c7af@abbot.galois.com>

#3333: GHCi doesn't load weak symbols
--------------------------------------+-------------------------------------
    Reporter:  heatsink               |        Owner:              
        Type:  bug                    |       Status:  new         
    Priority:  normal                 |    Milestone:  6.14.1      
   Component:  GHCi                   |      Version:  6.10.4      
    Keywords:  weak, dynamic loading  |   Difficulty:  Unknown     
          Os:  Linux                  |     Testcase:              
Architecture:  x86                    |      Failure:  None/Unknown
--------------------------------------+-------------------------------------

Comment(by hgolden):

 Replying to [ticket:3333 heatsink]:
 > GHCi fails to load modules with weak symbols.

 I want to clarify the current situation. GHCi's linker loads modules with
 weak symbols. However, it doesn't put the weak symbols into the symbol
 table.

 It would be easy to add weak symbols to the symbol table, but I'm not sure
 what the correct semantics should be. Perhaps weak symbols should be
 subordinated to global (STB_GLOBAL) and local (STB_LOCAL) symbols. Is this
 sufficient? (I haven't studied the documentation yet.)

 Question: Is it possible to have the same weak symbol defined in more than
 one module? If so, how does the linker choose?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3333#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 16 14:42:31 2010
From: trac at galois.com (GHC)
Date: Sat Jan 16 14:14:56 2010
Subject: [GHC] #3799: undefined symbols and undefined references
 possibly related to template haskell
In-Reply-To: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
References: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
Message-ID: <058.454248c56bbe260443f4912ab2135fe9@abbot.galois.com>

#3799: undefined symbols and undefined references possibly related to template
haskell
--------------------------------------------------------------+-------------
    Reporter:  JeremyShaw                                     |        Owner:                    
        Type:  bug                                            |       Status:  new               
    Priority:  normal                                         |    Milestone:  6.12.2            
   Component:  Compiler                                       |      Version:  6.13              
    Keywords:  undefined symbols references template haskell  |   Difficulty:                    
          Os:  Unknown/Multiple                               |     Testcase:                    
Architecture:  Unknown/Multiple                               |      Failure:  Compile-time crash
--------------------------------------------------------------+-------------
Changes (by AntoineLatter):

 * cc: AntoineLatter (added)


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 16 14:44:27 2010
From: trac at galois.com (GHC)
Date: Sat Jan 16 14:16:53 2010
Subject: [GHC] #3799: undefined symbols and undefined references
 possibly related to template haskell
In-Reply-To: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
References: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
Message-ID: <058.81252944d9f48be2803254b0fe493c0a@abbot.galois.com>

#3799: undefined symbols and undefined references possibly related to template
haskell
--------------------------------------------------------------+-------------
    Reporter:  JeremyShaw                                     |        Owner:                    
        Type:  bug                                            |       Status:  new               
    Priority:  normal                                         |    Milestone:  6.12.2            
   Component:  Compiler                                       |      Version:  6.13              
    Keywords:  undefined symbols references template haskell  |   Difficulty:                    
          Os:  Unknown/Multiple                               |     Testcase:                    
Architecture:  Unknown/Multiple                               |      Failure:  Compile-time crash
--------------------------------------------------------------+-------------

Comment(by AntoineLatter):

 Here's the thread on the happstack mailing list where I ran into the
 issue:
 http://groups.google.com/group/happs/browse_thread/thread/c66c74294d8eabf

 Here's a thread on the cafe with another instance:
 http://thread.gmane.org/gmane.comp.lang.haskell.cafe/69215

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 16 21:18:35 2010
From: trac at galois.com (GHC)
Date: Sat Jan 16 20:51:00 2010
Subject: [GHC] #3799: undefined symbols and undefined references
 possibly related to template haskell
In-Reply-To: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
References: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
Message-ID: <058.d4834b6949029e9307c1ff5f7b7b19c6@abbot.galois.com>

#3799: undefined symbols and undefined references possibly related to template
haskell
--------------------------------------------------------------+-------------
    Reporter:  JeremyShaw                                     |        Owner:                    
        Type:  bug                                            |       Status:  new               
    Priority:  normal                                         |    Milestone:  6.12.2            
   Component:  Compiler                                       |      Version:  6.13              
    Keywords:  undefined symbols references template haskell  |   Difficulty:                    
          Os:  Unknown/Multiple                               |     Testcase:                    
Architecture:  Unknown/Multiple                               |      Failure:  Compile-time crash
--------------------------------------------------------------+-------------

Comment(by AntoineLatter):

 I did a "cabal configure && cabal build" for syb-with-class, and then
 checked the timestamps on all of my .hi and .o files.
 I then did a "cabal haddock", and again checked the timestamps.

 It turns out that running "cabal haddock" rebuilds all of the .hi and .o
 files except HSsyb-with-class-0.6.1.o

 So now the .o file that we make our package out of is out of synch with
 the .hi files left over in dist/buid. This is probably almost always okay,
 except for when TH-generated names would end-up in the symbol table. (or
 if I edited the sources in between "cabal build" and "cabal haddock".

 Does that make this a bug with Cabal?

 Following is the dump from my terminal.

 >>>>>
 antoine-latters-macbook:syb-with-class-0.6.1 alatter$ find  . | grep \\.o$
 | xargs ls -l
 -rw-r--r--  1 alatter  staff  121496 Jan 16 20:04
 ./dist/build/Data/Generics/SYB/WithClass/Basics.o
 -rw-r--r--  1 alatter  staff    5888 Jan 16 20:04
 ./dist/build/Data/Generics/SYB/WithClass/Context.o
 -rw-r--r--  1 alatter  staff  157220 Jan 16 20:04
 ./dist/build/Data/Generics/SYB/WithClass/Derive.o
 -rw-r--r--  1 alatter  staff  403216 Jan 16 20:04
 ./dist/build/Data/Generics/SYB/WithClass/Instances.o
 -rw-r--r--  1 alatter  staff  602752 Jan 16 20:04 ./dist/build/HSsyb-with-
 class-0.6.1.o
 antoine-latters-macbook:syb-with-class-0.6.1 alatter$ find  . | grep
 \\.hi$ | xargs ls -l
 -rw-r--r--  1 alatter  staff   33600 Jan 16 20:04
 ./dist/build/Data/Generics/SYB/WithClass/Basics.hi
 -rw-r--r--  1 alatter  staff    2367 Jan 16 20:04
 ./dist/build/Data/Generics/SYB/WithClass/Context.hi
 -rw-r--r--  1 alatter  staff   13960 Jan 16 20:04
 ./dist/build/Data/Generics/SYB/WithClass/Derive.hi
 -rw-r--r--  1 alatter  staff  166039 Jan 16 20:04
 ./dist/build/Data/Generics/SYB/WithClass/Instances.hi
 antoine-latters-macbook:syb-with-class-0.6.1 alatter$ cabal haddock
 Running Haddock for syb-with-class-0.6.1...
 Preprocessing library syb-with-class-0.6.1...
 Warning: The documentation for the following packages are not installed.
 No
 links will be generated to these packages: ffi-1.0, rts-1.0
 Documentation created: dist/doc/html/syb-with-class/index.html
 antoine-latters-macbook:syb-with-class-0.6.1 alatter$ find  . | grep \\.o$
 | xargs ls -l
 -rw-r--r--  1 alatter  staff  121496 Jan 16 20:05
 ./dist/build/Data/Generics/SYB/WithClass/Basics.o
 -rw-r--r--  1 alatter  staff    5896 Jan 16 20:05
 ./dist/build/Data/Generics/SYB/WithClass/Context.o
 -rw-r--r--  1 alatter  staff  157220 Jan 16 20:05
 ./dist/build/Data/Generics/SYB/WithClass/Derive.o
 -rw-r--r--  1 alatter  staff  403216 Jan 16 20:05
 ./dist/build/Data/Generics/SYB/WithClass/Instances.o
 -rw-r--r--  1 alatter  staff  602752 Jan 16 20:04 ./dist/build/HSsyb-with-
 class-0.6.1.o
 antoine-latters-macbook:syb-with-class-0.6.1 alatter$ find  . | grep
 \\.hi$ | xargs ls -l
 -rw-r--r--  1 alatter  staff   33600 Jan 16 20:05
 ./dist/build/Data/Generics/SYB/WithClass/Basics.hi
 -rw-r--r--  1 alatter  staff    2367 Jan 16 20:05
 ./dist/build/Data/Generics/SYB/WithClass/Context.hi
 -rw-r--r--  1 alatter  staff   13960 Jan 16 20:05
 ./dist/build/Data/Generics/SYB/WithClass/Derive.hi
 -rw-r--r--  1 alatter  staff  166039 Jan 16 20:05
 ./dist/build/Data/Generics/SYB/WithClass/Instances.hi
 <<<<<

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 17 03:58:47 2010
From: trac at galois.com (GHC)
Date: Sun Jan 17 03:31:10 2010
Subject: [GHC] #3563: A couple of additions to Data.Bits
In-Reply-To: <045.1f98bcf2b0cef8bd6c1373dcce0d242a@abbot.galois.com>
References: <045.1f98bcf2b0cef8bd6c1373dcce0d242a@abbot.galois.com>
Message-ID: <054.5dffacfed8c4536cee5ff02c9c5e8ed9@abbot.galois.com>

#3563: A couple of additions to Data.Bits
---------------------------------+------------------------------------------
    Reporter:  porges            |        Owner:              
        Type:  proposal          |       Status:  new         
    Priority:  normal            |    Milestone:  Not GHC     
   Component:  libraries/base    |      Version:  6.11        
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by morrow):

  * failure:  => None/Unknown


Comment:

 I was just doing some bit twiddling the other day, here's some (C ->
 Haskell) stuff i ended up with:

 {{{
 pop64 :: Word64 -> Int
 pop64 x =
   let a = 0x5555555555555555
       b = 0x3333333333333333
       c = 0x0f0f0f0f0f0f0f0f
       d = 0x0101010101010101
   in case x - (x `shiftRL` 1) .&. a of
     x -> case (x .&. b) + ((x `shiftRL` 2) .&. b) of
       x -> case ((x + (x `shiftRL` 4)) .&. c) * d of
         x -> case x `shiftRL` 56 of
           x -> fromIntegral x

 bsr64 :: Word64 -> Int
 bsr64 x0 =
   case (x0 .|. shiftRL x0 1) of
     x1 -> case (x1 .|. shiftRL x1 2) of
       x2 -> case (x2 .|. shiftRL x2 4) of
         x3 -> case (x3 .|. shiftRL x3 8) of
           x4 -> case (x4 .|. shiftRL x4 16) of
             x5 -> case (x5 .|. shiftRL x5 32) of
               x6 -> case pop64 x6 - 1 of
                 x -> fromIntegral x

 -- from Data.IntMap
 shiftRL :: Word64 -> Int -> Word64
 shiftRL (W64# x) (I# i) = W64# (shiftRL# x i)
 }}}

 Matt

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3563#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 17 06:41:28 2010
From: trac at galois.com (GHC)
Date: Sun Jan 17 06:13:55 2010
Subject: [GHC] #3809: template-haskell 2.4 fails to compile with base 4.1
In-Reply-To: <049.ca9219b06862df97bec4403d1ce919ca@abbot.galois.com>
References: <049.ca9219b06862df97bec4403d1ce919ca@abbot.galois.com>
Message-ID: <058.2babd433584b0ac7e227cdf6aca4e89c@abbot.galois.com>

#3809: template-haskell 2.4 fails to compile with base 4.1
--------------------------------+-------------------------------------------
  Reporter:  benmachine         |          Owner:  igloo           
      Type:  bug                |         Status:  closed          
  Priority:  normal             |      Milestone:  6.12.2          
 Component:  libraries (other)  |        Version:  6.10.4          
Resolution:  fixed              |       Keywords:                  
Difficulty:                     |             Os:  Unknown/Multiple
  Testcase:                     |   Architecture:  Unknown/Multiple
   Failure:  Other              |  
--------------------------------+-------------------------------------------
Changes (by igloo):

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


Comment:

 Fixed in HEAD and 6.12 by:
 {{{
 Sat Jan 16 14:18:32 PST 2010  Ian Lynagh <igloo@earth.li>
   * Tighten the base dep; fixes trac #3809
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3809#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 17 06:42:46 2010
From: trac at galois.com (GHC)
Date: Sun Jan 17 06:15:13 2010
Subject: [GHC] #3792: Qualified names in import specifications
In-Reply-To: <044.0afdfc1c49ec255d82e9097f816e7649@abbot.galois.com>
References: <044.0afdfc1c49ec255d82e9097f816e7649@abbot.galois.com>
Message-ID: <053.1954dcae33c358f3129f4430d315448b@abbot.galois.com>

#3792: Qualified names in import specifications
---------------------------------------+------------------------------------
  Reporter:  nibro                     |          Owner:  igloo           
      Type:  merge                     |         Status:  closed          
  Priority:  normal                    |      Milestone:  6.12.2          
 Component:  Compiler                  |        Version:  6.12.1          
Resolution:  fixed                     |       Keywords:                  
Difficulty:                            |             Os:  Unknown/Multiple
  Testcase:  rename/should_fail/T3792  |   Architecture:  Unknown/Multiple
   Failure:  Other                     |  
---------------------------------------+------------------------------------
Changes (by igloo):

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


Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3792#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 17 06:43:42 2010
From: trac at galois.com (GHC)
Date: Sun Jan 17 06:16:06 2010
Subject: [GHC] #3761: 6.12.1 HC bootstrap failes due to suspicious
 static library ordering
In-Reply-To: <042.d80ddfbea544695de9a61d32ac79b9bd@abbot.galois.com>
References: <042.d80ddfbea544695de9a61d32ac79b9bd@abbot.galois.com>
Message-ID: <051.ad78927f548008467548122f3cebab9a@abbot.galois.com>

#3761: 6.12.1 HC bootstrap failes due to suspicious static library ordering
----------------------------------+-----------------------------------------
  Reporter:  PHO                  |          Owner:  igloo           
      Type:  bug                  |         Status:  closed          
  Priority:  normal               |      Milestone:  6.12.2          
 Component:  Build System         |        Version:  6.12.1          
Resolution:  fixed                |       Keywords:                  
Difficulty:                       |             Os:  Unknown/Multiple
  Testcase:                       |   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------
Changes (by igloo):

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


Comment:

 Fixed in 6.12 and HEAD by:
 {{{
 Sun Nov 15 09:54:05 PST 2009  Matthias Kilian <kili@outback.escape.de>
   * Reorder ALL_RTS_LIBS

   ALL_RTS_LIBS is (ab)used for linking ghc when BootingFromHc=Yes,
   which needs libHSrtsmain.a before libHSrts.a.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3761#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 17 07:34:08 2010
From: trac at galois.com (GHC)
Date: Sun Jan 17 07:06:35 2010
Subject: [GHC] #3794: Compiling a main program yields: /usr/bin/ld:
 cannot find -lHSrtsmain
In-Reply-To: <044.e1a190f33d758a6bb97e24503af072e1@abbot.galois.com>
References: <044.e1a190f33d758a6bb97e24503af072e1@abbot.galois.com>
Message-ID: <053.e70f04bcebbd0c2e3a72b8a207061c24@abbot.galois.com>

#3794: Compiling a main program yields: /usr/bin/ld: cannot find -lHSrtsmain
-----------------------------+----------------------------------------------
    Reporter:  guest         |        Owner:  igloo                
        Type:  bug           |       Status:  new                  
    Priority:  normal        |    Milestone:  6.12.2               
   Component:  Build System  |      Version:  6.12.1               
    Keywords:                |   Difficulty:                       
          Os:  Linux         |     Testcase:                       
Architecture:  x86           |      Failure:  Installing GHC failed
-----------------------------+----------------------------------------------

Comment(by igloo):

 I can't reproduce this.

 Can you please say exactly what commands you are running, what user you
 are running them as, and what the output of `umask` is?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3794#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 17 13:23:17 2010
From: trac at galois.com (GHC)
Date: Sun Jan 17 12:55:40 2010
Subject: [GHC] #3768: 6.12.1 Mac OS X installer lacks all HTML
 documentation
In-Reply-To: <052.9cb08ea2ad1c2eaf3d32d7297cdfbef7@abbot.galois.com>
References: <052.9cb08ea2ad1c2eaf3d32d7297cdfbef7@abbot.galois.com>
Message-ID: <061.2a8380e84552482e9aa1283401326e33@abbot.galois.com>

#3768: 6.12.1 Mac OS X installer lacks all HTML documentation
------------------------------+---------------------------------------------
    Reporter:  Minimiscience  |        Owner:  igloo            
        Type:  bug            |       Status:  new              
    Priority:  normal         |    Milestone:  6.12.2           
   Component:  Documentation  |      Version:  6.12.1           
    Keywords:                 |   Difficulty:                   
          Os:  MacOS X        |     Testcase:                   
Architecture:  x86            |      Failure:  Documentation bug
------------------------------+---------------------------------------------

Comment(by igloo):

 OK, the problem is that my Mac doesn't have the right docbook things
 installed, or they aren't installed in the right places. I've prodded it a
 bit, but got nowhere. If anyone knows how to fix this on OS X, please let
 me know:
 {{{
 checking for xmllint... /usr/bin/xmllint
 checking for DocBook DTD... I/O error : Attempt to load network entity
 http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
 conftest.xml:5: warning: failed to load external entity "http://www.oasis-
 open.org/docbook/xml/4.2/docbookx.dtd"
 [...]
 failed
 configure: WARNING: cannot find a DTD for DocBook XML V4.2, you will not
 be able to validate your documentation
 configure: WARNING: check your XML_CATALOG_FILES environment variable
 and/or /etc/xml/catalog
 checking for xsltproc... /usr/bin/xsltproc
 checking for DocBook XSL stylesheet... no
 configure: WARNING: cannot find DocBook XSL stylesheets, you will not be
 able to build the documentation
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3768#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 17 16:40:32 2010
From: trac at galois.com (GHC)
Date: Sun Jan 17 16:13:04 2010
Subject: [GHC] #3333: GHCi doesn't load weak symbols
In-Reply-To: <047.f7df20b3080234226b9f5744151738a8@abbot.galois.com>
References: <047.f7df20b3080234226b9f5744151738a8@abbot.galois.com>
Message-ID: <056.bdd070cda4449efde4430796263420cf@abbot.galois.com>

#3333: GHCi doesn't load weak symbols
--------------------------------------+-------------------------------------
    Reporter:  heatsink               |        Owner:              
        Type:  bug                    |       Status:  new         
    Priority:  normal                 |    Milestone:  6.14.1      
   Component:  GHCi                   |      Version:  6.10.4      
    Keywords:  weak, dynamic loading  |   Difficulty:  Unknown     
          Os:  Linux                  |     Testcase:              
Architecture:  x86                    |      Failure:  None/Unknown
--------------------------------------+-------------------------------------

Comment(by heatsink):

 > It would be easy to add weak symbols to the symbol table, but I'm not
 sure what the correct semantics should be. Perhaps weak symbols should be
 subordinated to global (STB_GLOBAL) and local (STB_LOCAL) symbols. Is this
 sufficient? (I haven't studied the documentation yet.)

 Weak symbols are never unified with local symbols.  Probably it's an error
 to have a weak and a local symbol with the same name in the same file.  I
 don't know what this means in terms of GHC's linker.

 > Question: Is it possible to have the same weak symbol defined in more
 than one module? If so, how does the linker choose?

 Yes.  AFAICT the choice is arbitrary.  GCC's linker's choice depends on
 the order that files are listed on the command line.  It is at least
 necessary to consider SHN_UNDEF when selecting a weak symbol (defined weak
 symbols take precedence over undefined weak symbols).

 The following statement from the ELF document appears to be relevant, but
 I don't know what extracting archive members has to do with symbol
 resolution.

 > The link editor does ''not'' extract archive members to resolve unde?ned
 weak symbols.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3333#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 17 17:27:16 2010
From: trac at galois.com (GHC)
Date: Sun Jan 17 16:59:49 2010
Subject: [GHC] #3333: GHCi doesn't load weak symbols
In-Reply-To: <047.f7df20b3080234226b9f5744151738a8@abbot.galois.com>
References: <047.f7df20b3080234226b9f5744151738a8@abbot.galois.com>
Message-ID: <056.ff7e42660f833657332e2a8f43866750@abbot.galois.com>

#3333: GHCi doesn't load weak symbols
--------------------------------------+-------------------------------------
    Reporter:  heatsink               |        Owner:  hgolden     
        Type:  bug                    |       Status:  assigned    
    Priority:  normal                 |    Milestone:  6.14.1      
   Component:  GHCi                   |      Version:  6.10.4      
    Keywords:  weak, dynamic loading  |   Difficulty:  Unknown     
          Os:  Linux                  |     Testcase:              
Architecture:  x86                    |      Failure:  None/Unknown
--------------------------------------+-------------------------------------
Changes (by hgolden):

  * owner:  => hgolden
  * status:  new => assigned


Comment:

 Replying to [comment:7 heatsink]:
 > > It would be easy to add weak symbols to the symbol table, but I'm not
 sure what the correct semantics should be. Perhaps weak symbols should be
 subordinated to global (STB_GLOBAL) and local (STB_LOCAL) symbols. Is this
 sufficient? (I haven't studied the documentation yet.)
 >
 > Weak symbols are never unified with local symbols.  Probably it's an
 error to have a weak and a local symbol with the same name in the same
 file.  I don't know what this means in terms of GHC's linker.

 I studied the documentation after writing my previous message. Local
 symbols stand alone. Global and weak symbols are in the same namespace,
 but global symbols take priority.

 > > Question: Is it possible to have the same weak symbol defined in more
 than one module? If so, how does the linker choose?
 >
 > Yes.  AFAICT the choice is arbitrary.  GCC's linker's choice depends on
 the order that files are listed on the command line.  It is at least
 necessary to consider SHN_UNDEF when selecting a weak symbol (defined weak
 symbols take precedence over undefined weak symbols).

 OK. Then I think the following approach would work:

 1. Add local, global and the first occurrence of a weak symbol to the
 symbol table (if the global symbol doesn't exist already). It is allowable
 to have all 3 types of a single name in the symbol table.

 2. When a local symbol is called for, return that. When a global symbol is
 called for, return the global symbol if it exists. If a global symbol
 doesn't exist, return a weak symbol if it exists.

 I believe this can be implemented in the rts/Linker.c in a straightforward
 way. I will start working on this. If you disagree with my analysis of the
 semantics, please let me know what you want instead.

 > The following statement from the ELF document appears to be relevant,
 but I don't know what extracting archive members has to do with symbol
 resolution.
 >
 > > The link editor does ''not'' extract archive members to resolve
 unde?ned weak symbols.

 I don't think this is relevant for the GHCi linker, since it only loads
 modules on demand and doesn't try to resolve undefined symbols at all.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3333#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 17 19:01:19 2010
From: trac at galois.com (GHC)
Date: Sun Jan 17 18:33:40 2010
Subject: [GHC] #3824: parse error on gadt pragma
Message-ID: <044.b316b7444790defb35a24e3ddff37a3a@abbot.galois.com>

#3824: parse error on gadt pragma
-------------------------------+--------------------------------------------
    Reporter:  guest           |       Owner:              
        Type:  bug             |      Status:  new         
    Priority:  normal          |   Component:  Compiler    
     Version:  6.10.4          |    Keywords:              
          Os:  Linux           |    Testcase:              
Architecture:  x86_64 (amd64)  |     Failure:  None/Unknown
-------------------------------+--------------------------------------------
 I have a file "zap.hs" containing the single line

   {-# LANGUAGE: GADTs #-}

 trying to load it into ghci or runhaskell zap.hs results in:

 ghc: panic! (the 'impossible' happened)
   (GHC version 6.10.4 for x86_64-unknown-linux):
         getOptions'.parseLanguage(2) went past eof token

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3824>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 03:56:08 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 03:28:34 2010
Subject: [GHC] #3260: Linking stage2 on PPC gives "scattered reloc
 r_address too large"
In-Reply-To: <043.9087f80d620051a542dc03d51ff19b43@abbot.galois.com>
References: <043.9087f80d620051a542dc03d51ff19b43@abbot.galois.com>
Message-ID: <052.8cc231973d5f6ab71d1e7a8281655f30@abbot.galois.com>

#3260: Linking stage2 on PPC gives "scattered reloc r_address too large"
-------------------------+--------------------------------------------------
    Reporter:  benl      |        Owner:              
        Type:  bug       |       Status:  new         
    Priority:  normal    |    Milestone:  _|_         
   Component:  Compiler  |      Version:  6.11        
    Keywords:            |   Difficulty:  Unknown     
          Os:  MacOS X   |     Testcase:              
Architecture:  powerpc   |      Failure:  None/Unknown
-------------------------+--------------------------------------------------
Changes (by PHO):

 * cc: pho@? (added)


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3260#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 04:23:13 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 03:55:42 2010
Subject: [GHC] #1845: unconditional relative branch out of range (GHC
 version 6.8.1/6.8.2 for powerpc_apple_darwin)
In-Reply-To: <044.65389402080b2ab045a1b2fde12245f8@abbot.galois.com>
References: <044.65389402080b2ab045a1b2fde12245f8@abbot.galois.com>
Message-ID: <053.d72ff4e196700d2291612590d3e874f3@abbot.galois.com>

#1845: unconditional relative branch out of range (GHC version 6.8.1/6.8.2 for
powerpc_apple_darwin)
-------------------------+--------------------------------------------------
    Reporter:  guest     |        Owner:  thorkilnaur 
        Type:  bug       |       Status:  new         
    Priority:  normal    |    Milestone:  _|_         
   Component:  Compiler  |      Version:  6.10.4      
    Keywords:            |   Difficulty:  Unknown     
          Os:  MacOS X   |     Testcase:              
Architecture:  powerpc   |      Failure:  None/Unknown
-------------------------+--------------------------------------------------
Changes (by PHO):

 * cc: pho@? (added)


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1845#comment:17>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 04:59:25 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 04:31:45 2010
Subject: [GHC] #3799: undefined symbols and undefined references
 possibly related to template haskell
In-Reply-To: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
References: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
Message-ID: <058.2eed17469a3917dd2f0056cf83f7ec08@abbot.galois.com>

#3799: undefined symbols and undefined references possibly related to template
haskell
---------------------------------+------------------------------------------
  Reporter:  JeremyShaw          |          Owner:                                               
      Type:  bug                 |         Status:  closed                                       
  Priority:  normal              |      Milestone:  6.12.2                                       
 Component:  Compiler            |        Version:  6.13                                         
Resolution:  invalid             |       Keywords:  undefined symbols references template haskell
Difficulty:                      |             Os:  Unknown/Multiple                             
  Testcase:                      |   Architecture:  Unknown/Multiple                             
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Changes (by simonpj):

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


Comment:

 Thank you for investigating this.  It looks as if my hypothesis was right:
 Cabal is causing you to (a) compile a module against M.hi, but then (b)
 link against an M.o that was generated by a different call of GHC. That's
 simply not supported by GHC: .hi and .o files are indissolubly bound
 together.

 So I declare this a Cabal bug.  Antoine has helpfully opened a Cabal
 ticket for it
 http://hackage.haskell.org/trac/hackage/ticket/624, so I'll close this one
 as "invalid" (ie not GHC's problem).

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 06:18:41 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 05:51:02 2010
Subject: [GHC] #3820: Pragma for suppressing 'orphan instance' warnings
 per instance
In-Reply-To: <044.744018ec3a95e53b8f2d7e0ead54e910@abbot.galois.com>
References: <044.744018ec3a95e53b8f2d7e0ead54e910@abbot.galois.com>
Message-ID: <053.bc1e0e4d4903af3775847d2f27f891f3@abbot.galois.com>

#3820: Pragma for suppressing 'orphan instance' warnings per instance
--------------------------------------+-------------------------------------
  Reporter:  guest                    |          Owner:                  
      Type:  feature request          |         Status:  closed          
  Priority:  normal                   |      Milestone:                  
 Component:  Compiler (Type checker)  |        Version:  6.12.1          
Resolution:  duplicate                |       Keywords:                  
Difficulty:                           |             Os:  Unknown/Multiple
  Testcase:                           |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown             |  
--------------------------------------+-------------------------------------
Changes (by simonmar):

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


Comment:

 Duplicate of #602

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3820#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 06:19:04 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 05:51:24 2010
Subject: [GHC] #602: Warning Suppression
In-Reply-To: <047.d851345fc677a304d933040775d25d45@abbot.galois.com>
References: <047.d851345fc677a304d933040775d25d45@abbot.galois.com>
Message-ID: <056.4f9f25c33aea0a98667391e392f4bedf@abbot.galois.com>

#602: Warning Suppression
-----------------------------------------+----------------------------------
  Reporter:  simonmar                    |          Owner:                  
      Type:  task                        |         Status:  new             
  Priority:  normal                      |      Milestone:  6.12 branch     
 Component:  Compiler                    |        Version:  None            
Resolution:  None                        |       Keywords:  warnings        
Difficulty:  Moderate (less than a day)  |             Os:  Unknown/Multiple
  Testcase:  N/A                         |   Architecture:  Unknown/Multiple
   Failure:  Other                       |  
-----------------------------------------+----------------------------------

Comment(by simonmar):

 See also #3820

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/602#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 06:53:57 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 06:26:17 2010
Subject: [GHC] #3823: GHC 6.12 breaks combination of records and
 mutually recursive modules
In-Reply-To: <044.7cc1ab77124bd237b37d840aa7398830@abbot.galois.com>
References: <044.7cc1ab77124bd237b37d840aa7398830@abbot.galois.com>
Message-ID: <053.94db524c3e0b99fa179f2caf000d4ecd@abbot.galois.com>

#3823: GHC 6.12 breaks combination of records and mutually recursive modules
---------------------------------+------------------------------------------
    Reporter:  mboes             |        Owner:                           
        Type:  bug               |       Status:  new                      
    Priority:  high              |    Milestone:  6.12.2                   
   Component:  Compiler          |      Version:  6.12.1                   
    Keywords:                    |   Difficulty:                           
          Os:  Unknown/Multiple  |     Testcase:                           
Architecture:  Unknown/Multiple  |      Failure:  GHC rejects valid program
---------------------------------+------------------------------------------
Changes (by simonmar):

  * priority:  normal => high
  * milestone:  => 6.12.2


Comment:

 regression

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3823#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 07:00:28 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 06:32:55 2010
Subject: [GHC] #3824: parse error on gadt pragma
In-Reply-To: <044.b316b7444790defb35a24e3ddff37a3a@abbot.galois.com>
References: <044.b316b7444790defb35a24e3ddff37a3a@abbot.galois.com>
Message-ID: <053.d4baa504b60febe0ef201bb147afbf8e@abbot.galois.com>

#3824: parse error on gadt pragma
---------------------------+------------------------------------------------
  Reporter:  guest         |          Owner:                
      Type:  bug           |         Status:  closed        
  Priority:  normal        |      Milestone:                
 Component:  Compiler      |        Version:  6.10.4        
Resolution:  duplicate     |       Keywords:                
Difficulty:                |             Os:  Linux         
  Testcase:                |   Architecture:  x86_64 (amd64)
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by simonmar):

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


Comment:

 Thanks for the report.  This is a duplicate of #3153, fixed in 6.12.1 (you
 need to remove the ':' from 'LANGUAGE:').

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3824#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 07:08:54 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 06:41:16 2010
Subject: [GHC] #3799: undefined symbols and undefined references
 possibly related to template haskell
In-Reply-To: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
References: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
Message-ID: <058.7156cdc93aea6d07f34d32209e490541@abbot.galois.com>

#3799: undefined symbols and undefined references possibly related to template
haskell
---------------------------------+------------------------------------------
  Reporter:  JeremyShaw          |          Owner:                                               
      Type:  bug                 |         Status:  closed                                       
  Priority:  normal              |      Milestone:  6.12.2                                       
 Component:  Compiler            |        Version:  6.13                                         
Resolution:  invalid             |       Keywords:  undefined symbols references template haskell
Difficulty:                      |             Os:  Unknown/Multiple                             
  Testcase:                      |   Architecture:  Unknown/Multiple                             
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------

Comment(by simonmar):

 It may be mitigated by this recent patch:

 {{{
 Tue Jan 12 14:58:53 PST 2010  Simon Marlow <marlowsd@gmail.com>
   * Do some recompilation avoidance in GHC.loadModule
   GHC.loadModule compiles a module after it has been parsed and
   typechecked explicity. If we are compiling to object code and there is
   a valid object file already on disk, then we can skip the compilation
   step. This is useful in Haddock, when processing a package that uses
   Template Haskell and hence needs actual compilation, and the package
   has already been compiled.

   As usual, the recomp avoidance can be disabled with -fforce-recomp.

     M ./compiler/main/GHC.hs -7 +17
     M ./compiler/main/HscMain.lhs +17
 }}}

 because this should mean that `cabal haddock` won't do any actual
 recompilation if the package is already built.  It's not a robust fix,
 since if you modify a source file then `cabal haddock` will still do some
 compilation without updating the `HSsyb-with-class-0.6.1.o` file.

 The sledgehammer fix in Cabal (use a different `-odir` when haddocking)
 will avoid the problem, but at the cost of forcing `cabal haddock` to
 compile everything.  I suggest a better fix might be for `cabal haddock`
 to invoke `cabal build` before running Haddock, to ensure that the object
 files are up to date.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 07:11:08 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 06:43:28 2010
Subject: [GHC] #3821: Trace.Hpc.Reflect.examineTix segfaults on 64bit
In-Reply-To: <053.fbf59e92eb99357652de0927fec4376a@abbot.galois.com>
References: <053.fbf59e92eb99357652de0927fec4376a@abbot.galois.com>
Message-ID: <062.9640449c4c7ba59dc5ed49b6ad9c2612@abbot.galois.com>

#3821: Trace.Hpc.Reflect.examineTix segfaults on 64bit
---------------------------------+------------------------------------------
    Reporter:  TristanAllwood    |        Owner:  andy@?         
        Type:  bug               |       Status:  new            
    Priority:  high              |    Milestone:  6.12.2         
   Component:  Code Coverage     |      Version:  6.12.1         
    Keywords:                    |   Difficulty:                 
          Os:  Unknown/Multiple  |     Testcase:                 
Architecture:  x86_64 (amd64)    |      Failure:  None/Unknown   
---------------------------------+------------------------------------------
Changes (by simonmar):

  * priority:  normal => high
  * milestone:  => 6.12.2


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3821#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 07:42:25 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 07:14:46 2010
Subject: [GHC] #3823: GHC 6.12 breaks combination of records and
 mutually recursive modules
In-Reply-To: <044.7cc1ab77124bd237b37d840aa7398830@abbot.galois.com>
References: <044.7cc1ab77124bd237b37d840aa7398830@abbot.galois.com>
Message-ID: <053.fba2e2a82950346a52b926db34e6c4c4@abbot.galois.com>

#3823: GHC 6.12 breaks combination of records and mutually recursive modules
---------------------------------+------------------------------------------
    Reporter:  mboes             |        Owner:  simonpj                  
        Type:  bug               |       Status:  new                      
    Priority:  high              |    Milestone:  6.12.2                   
   Component:  Compiler          |      Version:  6.12.1                   
    Keywords:                    |   Difficulty:                           
          Os:  Unknown/Multiple  |     Testcase:                           
Architecture:  Unknown/Multiple  |      Failure:  GHC rejects valid program
---------------------------------+------------------------------------------
Changes (by simonpj):

  * owner:  => simonpj


Comment:

 I'm on this.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3823#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 08:25:51 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 07:58:11 2010
Subject: [GHC] #3813: Invalid warning from GHCi
In-Reply-To: <051.207c96ece971d6767ecb4b1e779ba7b2@abbot.galois.com>
References: <051.207c96ece971d6767ecb4b1e779ba7b2@abbot.galois.com>
Message-ID: <060.aa9ea239e06d443f478260b69da4478b@abbot.galois.com>

#3813: Invalid warning from GHCi
---------------------------------+------------------------------------------
    Reporter:  NeilMitchell      |        Owner:  simonpj                          
        Type:  bug               |       Status:  new                              
    Priority:  normal            |    Milestone:  6.12.2                           
   Component:  GHCi              |      Version:  6.10.4                           
    Keywords:                    |   Difficulty:                                   
          Os:  Unknown/Multiple  |     Testcase:                                   
Architecture:  Unknown/Multiple  |      Failure:  Incorrect warning at compile-time
---------------------------------+------------------------------------------
Changes (by simonpj):

  * owner:  => simonpj


Comment:

 I'm on this.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3813#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 09:05:42 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 08:38:01 2010
Subject: [GHC] #3825: "went past eof token" crash when using
 -XOverLoadedStrings
Message-ID: <044.8598664cc19c0f05568be65b20b3492e@abbot.galois.com>

#3825: "went past eof token" crash when using -XOverLoadedStrings
-------------------------------+--------------------------------------------
    Reporter:  guest           |       Owner:                    
        Type:  bug             |      Status:  new               
    Priority:  normal          |   Component:  Compiler          
     Version:  6.10.4          |    Keywords:  xoverloadedstrings
          Os:  Linux           |    Testcase:                    
Architecture:  x86_64 (amd64)  |     Failure:  Compile-time crash
-------------------------------+--------------------------------------------
 When trying to compile the following file:

     {-# LANGUAGE -XOverLoadedStrings #-}

     main = PutStrLn "meow"

 I get the following error message:

     ghc: panic! (the 'impossible' happened)

     (GHC version 6.10.4 for x86_64-unknown-linux):

     getOptions'.parseLanguage(2) went past eof token

     Please report this as a GHC bug:  -link to ghc reportabug-

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3825>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 10:02:37 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 09:34:56 2010
Subject: [GHC] #3764: need --htmldir conifiguration
In-Reply-To: <050.747b1712677f28ce0bf9a45c7d03b30b@abbot.galois.com>
References: <050.747b1712677f28ce0bf9a45c7d03b30b@abbot.galois.com>
Message-ID: <059.6f8dc8be6143cf152244798fd8904d19@abbot.galois.com>

#3764: need --htmldir conifiguration
------------------------------+---------------------------------------------
  Reporter:  juhpetersen      |          Owner:  igloo           
      Type:  feature request  |         Status:  closed          
  Priority:  normal           |      Milestone:  6.12.2          
 Component:  Build System     |        Version:  6.12.1          
Resolution:  worksforme       |       Keywords:                  
Difficulty:                   |             Os:  Unknown/Multiple
  Testcase:                   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown     |  
------------------------------+---------------------------------------------
Changes (by igloo):

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


Comment:

 This works for me, e.g. in the 6.12 branch:
 {{{
 $ ./configure --htmldir=/wibble
 $ make show VALUE=htmldir
 htmldir="/wibble"
 }}}
 but the version of autoconf used needs to be sufficiently recent that it
 knows about the htmldir flag.

 I'll push a patch updating some of the comments in install.mk.in.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3764#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 10:59:51 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 10:32:11 2010
Subject: [GHC] #3825: "went past eof token" crash when using
 -XOverLoadedStrings
In-Reply-To: <044.8598664cc19c0f05568be65b20b3492e@abbot.galois.com>
References: <044.8598664cc19c0f05568be65b20b3492e@abbot.galois.com>
Message-ID: <053.e9d25550efdef6875fdf8a617840202e@abbot.galois.com>

#3825: "went past eof token" crash when using -XOverLoadedStrings
-------------------------------+--------------------------------------------
Reporter:  guest               |          Owner:                
    Type:  bug                 |         Status:  closed        
Priority:  normal              |      Component:  Compiler      
 Version:  6.10.4              |     Resolution:  duplicate     
Keywords:  xoverloadedstrings  |             Os:  Linux         
Testcase:                      |   Architecture:  x86_64 (amd64)
 Failure:  Compile-time crash  |  
-------------------------------+--------------------------------------------
Changes (by isaacdupree):

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


Comment:

 the correct language pragma is punctuated and capitalized this way:
 {{{
 {-# LANGUAGE OverloadedStrings #-}
 }}}
 The bad error message is a much-reported GHC bug, fixed in 6.12.1.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3825#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 14:07:56 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 13:40:28 2010
Subject: [GHC] #3333: GHCi doesn't load weak symbols
In-Reply-To: <047.f7df20b3080234226b9f5744151738a8@abbot.galois.com>
References: <047.f7df20b3080234226b9f5744151738a8@abbot.galois.com>
Message-ID: <056.1d9f4c7bd27b34cc96c7f59fe4dd55ed@abbot.galois.com>

#3333: GHCi doesn't load weak symbols
--------------------------------------+-------------------------------------
    Reporter:  heatsink               |        Owner:  hgolden     
        Type:  bug                    |       Status:  assigned    
    Priority:  normal                 |    Milestone:  6.14.1      
   Component:  GHCi                   |      Version:  6.10.4      
    Keywords:  weak, dynamic loading  |   Difficulty:  Unknown     
          Os:  Linux                  |     Testcase:              
Architecture:  x86                    |      Failure:  None/Unknown
--------------------------------------+-------------------------------------

Comment(by heatsink):

 Replying to [comment:8 hgolden]:

 > OK. Then I think the following approach would work:
 >
 > 1. Add local, global and the first occurrence of a weak symbol to the
 symbol table (if the global symbol doesn't exist already). It is allowable
 to have all 3 types of a single name in the symbol table.
 >
 > 2. When a local symbol is called for, return that. When a global symbol
 is called for, return the global symbol if it exists. If a global symbol
 doesn't exist, return a weak symbol if it exists.

 There are three cases when a global symbol is called for.
  1. If the global symbol is defined, return it.
  2. Otherwise, if a weak symbol is defined in the table, return it.
  3. Otherwise, if a weak symbol is in the table and marked "undefined",
 return NULL.
  4. Otherwise, report an error because the symbol is undefined.

 Weak undefined symbols can satisfy a need for a symbol, in contrast to
 global undefined symbols which cannot.  Weak undefined symbols are
 sometimes used in the C/C++ domain as a way of allowing optional hooks or
 callbacks.

 > I believe this can be implemented in the rts/Linker.c in a
 straightforward way. I will start working on this. If you disagree with my
 analysis of the semantics, please let me know what you want instead.

 There is one complication due to incremental linking.  We could have a
 situation where a symbol's value changes as a result of module imports:

  * load A.o which uses X (global undefined) [[BR]] and B.o which defines X
 = 1 (weak defined)
  * call a function in A, which reveals that X has the value 1
  * load C.o which defines X = 2 (global defined) [[BR]] and D.o which uses
 X (global undefined) [[BR]] Although X had the value 1 before, the global
 definition takes precedence over the weak definition so it now has the
 value 2
  * call a function in D, which reveals that X has the value 2
  * call a function in A, which reveals that X has the value 1
 (inconsistent) or 2 (not referentially transparent)

 I think that to avoid problems, it has to be detected whenever loading new
 modules would change a symbol's value.  GHCi already detects redefined
 global symbols, so hopefully you can reuse that.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3333#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 14:42:23 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 14:14:54 2010
Subject: [GHC] #3333: GHCi doesn't load weak symbols
In-Reply-To: <047.f7df20b3080234226b9f5744151738a8@abbot.galois.com>
References: <047.f7df20b3080234226b9f5744151738a8@abbot.galois.com>
Message-ID: <056.129c31ad8550ae9adfaf9b6006711a32@abbot.galois.com>

#3333: GHCi doesn't load weak symbols
--------------------------------------+-------------------------------------
    Reporter:  heatsink               |        Owner:  hgolden     
        Type:  bug                    |       Status:  assigned    
    Priority:  normal                 |    Milestone:  6.14.1      
   Component:  GHCi                   |      Version:  6.10.4      
    Keywords:  weak, dynamic loading  |   Difficulty:  Unknown     
          Os:  Linux                  |     Testcase:              
Architecture:  x86                    |      Failure:  None/Unknown
--------------------------------------+-------------------------------------

Comment(by hgolden):

 Replying to [comment:9 heatsink]:

 > There is one complication due to incremental linking.  We could have a
 situation where a symbol's value changes as a result of module imports:
 >
 >  * load A.o which uses X (global undefined) [[BR]] and B.o which defines
 X = 1 (weak defined)
 >  * call a function in A, which reveals that X has the value 1
 >  * load C.o which defines X = 2 (global defined) [[BR]] and D.o which
 uses X (global undefined) [[BR]] Although X had the value 1 before, the
 global definition takes precedence over the weak definition so it now has
 the value 2
 >  * call a function in D, which reveals that X has the value 2
 >  * call a function in A, which reveals that X has the value 1
 (inconsistent) or 2 (not referentially transparent)
 >
 > I think that to avoid problems, it has to be detected whenever loading
 new modules would change a symbol's value.  GHCi already detects redefined
 global symbols, so hopefully you can reuse that.

 Here's my approach to that:

 1. (Currently) redefining a global symbol is an error (that terminates the
 program). This wouldn't change.
 2. When a weak symbol is defined and there is no defined global symbol,
 save the first defined weak symbol. (In other words, only save the first
 weak definition, if at all.)
 3. When a weak symbol is "resolved" (actually called for in another
 module), it becomes a global symbol. The reason for this is that case 1
 should follow if there is any global symbol defined later. This avoids the
 problems you have noted above.
 4. If the weak symbol hasn't been "upgraded" to a global symbol by case 3,
 it will be superseded by a global symbol definition.

 This approach is somewhat conservative, since a weak definition that
 hasn't been "used" (i.e., called or accessed), as opposed to "resolved,"
 could be replaced by a global definition. However, to implement this would
 require some method of determining the first use of a symbol. (Perhaps
 this could be done, but I don't plan to implement it at present.)

 To implement this, only one version of a global/weak symbol needs to be
 saved in the defined symbol table. (This revises my earlier statement that
 global and weak symbols with the same name would need to co-exist in the
 symbol table.)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3333#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 15:07:42 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 14:40:12 2010
Subject: [GHC] #3333: GHCi doesn't load weak symbols
In-Reply-To: <047.f7df20b3080234226b9f5744151738a8@abbot.galois.com>
References: <047.f7df20b3080234226b9f5744151738a8@abbot.galois.com>
Message-ID: <056.57513b0f8b0f88903f4b2d4a094ddb22@abbot.galois.com>

#3333: GHCi doesn't load weak symbols
--------------------------------------+-------------------------------------
    Reporter:  heatsink               |        Owner:  hgolden     
        Type:  bug                    |       Status:  assigned    
    Priority:  normal                 |    Milestone:  6.14.1      
   Component:  GHCi                   |      Version:  6.10.4      
    Keywords:  weak, dynamic loading  |   Difficulty:  Unknown     
          Os:  Linux                  |     Testcase:              
Architecture:  x86                    |      Failure:  None/Unknown
--------------------------------------+-------------------------------------

Comment(by heatsink):

 That resolution method [[comment:10]] looks good to me.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3333#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 18:22:53 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 17:55:19 2010
Subject: [GHC] #3784: --with-gmp-includes and --with-gmp-libraries don't
 affect the building process of
 integer-gmp/cbits/mkGmpDerivedConstants
In-Reply-To: <042.086ff891f8fafb9e8c853a08131127e3@abbot.galois.com>
References: <042.086ff891f8fafb9e8c853a08131127e3@abbot.galois.com>
Message-ID: <051.40732996eeb03a5066dfc220d94921c4@abbot.galois.com>

#3784: --with-gmp-includes and --with-gmp-libraries don't affect the building
process of integer-gmp/cbits/mkGmpDerivedConstants
----------------------------------+-----------------------------------------
  Reporter:  PHO                  |          Owner:  igloo           
      Type:  bug                  |         Status:  closed          
  Priority:  normal               |      Milestone:  6.12.2          
 Component:  libraries/base       |        Version:  6.12.1          
Resolution:  fixed                |       Keywords:  integer-gmp     
Difficulty:                       |             Os:  Unknown/Multiple
  Testcase:                       |   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------
Changes (by igloo):

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


Comment:

 Fixed by:
 {{{
 Mon Jan 18 19:18:31 GMT 2010  Ian Lynagh <igloo@earth.li>
   * Pass GMP paths when compiling mkGmpDerivedConstants; fixes trac #3784
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3784#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 18 18:23:46 2010
From: trac at galois.com (GHC)
Date: Mon Jan 18 17:56:05 2010
Subject: [GHC] #3796: GHC 6.12 dependency checking many times slower
 than 6.10
In-Reply-To: <048.1804574c402b028604cc65b754fd78d4@abbot.galois.com>
References: <048.1804574c402b028604cc65b754fd78d4@abbot.galois.com>
Message-ID: <057.30d25d40d77af88bc3624b34bff193c3@abbot.galois.com>

#3796: GHC 6.12 dependency checking many times slower than 6.10
-------------------------------------------+--------------------------------
  Reporter:  sunrayser                     |          Owner:  igloo 
      Type:  merge                         |         Status:  closed
  Priority:  high                          |      Milestone:  6.12.2
 Component:  Compiler                      |        Version:  6.12.1
Resolution:  fixed                         |       Keywords:        
Difficulty:                                |             Os:  Linux 
  Testcase:                                |   Architecture:  x86   
   Failure:  Compile-time performance bug  |  
-------------------------------------------+--------------------------------
Changes (by igloo):

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


Comment:

 Merged.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3796#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 05:29:32 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 05:01:53 2010
Subject: [GHC] #3826: Can't infer type (type family as "element" type)
Message-ID: <042.84e771ed5687c0b090cc1169d5855922@abbot.galois.com>

#3826: Can't infer type (type family as "element" type)
---------------------------------+------------------------------------------
    Reporter:  spl               |       Owner:                           
        Type:  bug               |      Status:  new                      
    Priority:  normal            |   Component:  Compiler (Type checker)  
     Version:  6.12.1            |    Keywords:  type families            
          Os:  Unknown/Multiple  |    Testcase:                           
Architecture:  Unknown/Multiple  |     Failure:  GHC rejects valid program
---------------------------------+------------------------------------------
 Suppose I have a class C,

 {{{
 class C a where
   type E a
   c :: E a -> a -> a
 }}}

 a datatype T,

 {{{
 data T a = T a
 }}}

 and an instance of C for T

 {{{
 instance C (T a) where
   type E (T a) = a
   c x (T _) = T x
 }}}

 I would like to write a function such as f

 {{{
 f t@(T x) = c x t
 }}}

 without a type signature. Unfortunately, I can't because GHC tells me

 {{{
     Couldn't match expected type `t' against inferred type `T (E t)'
     In the second argument of `c', namely `t'
     In the expression: c x t
     In the definition of `f': f (t@(T x)) = c x t
 }}}

 There are at least three possible ways to write the above code such
 that it works.

 (1) Give a type signature for f

 {{{
 f :: T a -> T a
 }}}

 (2) Define the class C using an equality constraint

 {{{
 class C t where
   type E t
   c :: (E t ~ e) => e -> t -> t
 }}}

 (3) Define the class C using functional dependencies

 {{{
 class C t e | t -> e where
   c :: e -> t -> t
 }}}

 But the real question is why don't I get a type for f?

 This has been tested in GHC 6.10.1 and 6.12.1.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3826>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 09:34:11 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 09:06:30 2010
Subject: [GHC] #3827: Compiling fails on linux-powerpc
Message-ID: <050.513cd5a1d672cd1796d29f3e29565e48@abbot.galois.com>

#3827: Compiling fails on linux-powerpc
----------------------------+-----------------------------------------------
    Reporter:  speleologic  |       Owner:                     
        Type:  bug          |      Status:  new                
    Priority:  normal       |   Component:  Compiler           
     Version:  6.12.1       |    Keywords:                     
          Os:  Linux        |    Testcase:                     
Architecture:  powerpc      |     Failure:  Building GHC failed
----------------------------+-----------------------------------------------
 I get the following error after doing ./configure && make

 ghc-stage1: panic! (the 'impossible' happened)
   (GHC version 6.12.1 for powerpc-unknown-linux):
         Error in array index

 The command where the failure happens is:

 "inplace/bin/ghc-stage1"   -H32m -O    -package-name ghc-prim-0.2.0.0
 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-
 install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries
 /ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-
 install/build/autogen -Ilibraries/ghc-prim/.    -optP-include
 -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package
 rts-1.0 -split-objs -package-name ghc-prim -XCPP -XMagicHash
 -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples
 -XEmptyDataDecls -XNoImplicitPrelude -O2 -XGenerics -fno-warn-deprecated-
 flags     -odir libraries/ghc-prim/dist-install/build -hidir libraries
 /ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-
 install/build -hisuf hi -osuf  o -hcsuf hc -c libraries/ghc-
 prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3827>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 10:43:59 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 10:16:27 2010
Subject: [GHC] #3742: redundant space in FFI imports rejected by 6.12
In-Reply-To: <045.5c4f82a5466765e359b1173caa6982ac@abbot.galois.com>
References: <045.5c4f82a5466765e359b1173caa6982ac@abbot.galois.com>
Message-ID: <054.d7decfbb638b1cd2db71669035d128a3@abbot.galois.com>

#3742: redundant space in FFI imports rejected by 6.12
----------------------------------------+-----------------------------------
  Reporter:  duncan                     |          Owner:  igloo           
      Type:  merge                      |         Status:  closed          
  Priority:  normal                     |      Milestone:  6.12.2          
 Component:  Compiler (Parser)          |        Version:  6.12.1 RC1      
Resolution:  fixed                      |       Keywords:                  
Difficulty:                             |             Os:  Unknown/Multiple
  Testcase:                             |   Architecture:  Unknown/Multiple
   Failure:  GHC rejects valid program  |  
----------------------------------------+-----------------------------------
Changes (by igloo):

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


Comment:

 Merged.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3742#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 10:44:19 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 10:16:37 2010
Subject: [GHC] #3762: filepath.cabal has an extraneous apostrophe
In-Reply-To: <048.0e334d3f10da19941e936444bdd1074c@abbot.galois.com>
References: <048.0e334d3f10da19941e936444bdd1074c@abbot.galois.com>
Message-ID: <057.dd0d19fd8068a0c5b85431c77eb7a384@abbot.galois.com>

#3762: filepath.cabal has an extraneous apostrophe
--------------------------------+-------------------------------------------
  Reporter:  ohnobinki          |          Owner:  igloo           
      Type:  merge              |         Status:  closed          
  Priority:  normal             |      Milestone:  6.12.2          
 Component:  libraries (other)  |        Version:                  
Resolution:  fixed              |       Keywords:  filepath        
Difficulty:                     |             Os:  Unknown/Multiple
  Testcase:                     |   Architecture:  Unknown/Multiple
   Failure:  Documentation bug  |  
--------------------------------+-------------------------------------------
Changes (by igloo):

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


Comment:

 Fixed in 6.12 by:
 {{{
 Tue Jan 19 13:32:32 GMT 2010  Ian Lynagh <igloo@earth.li>
   * Update to a newer version of filepath; fixes trac #3762
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3762#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 11:40:32 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 11:12:49 2010
Subject: [GHC] #3828: Error in array index
Message-ID: <042.183a30ca9d84f0b1998a7b985bfd6d87@abbot.galois.com>

#3828: Error in array index
------------------------+---------------------------------------------------
    Reporter:  CBa      |       Owner:                    
        Type:  bug      |      Status:  new               
    Priority:  normal   |   Component:  Compiler          
     Version:  6.12.1   |    Keywords:  sunos             
          Os:  Solaris  |    Testcase:                    
Architecture:  sparc    |     Failure:  Compile-time crash
------------------------+---------------------------------------------------
 I simply compile ghc-6.12.1 on solaris with ghc 6.8.3.

 when compiling libraries/ghc-prim/./GHC/Types.hs:

 ghc-stage1: panic! (the 'impossible' happened)
   (GHC version 6.12.1 for sparc-sun-solaris2):
         Error in array index

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3828>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 11:47:04 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 11:19:46 2010
Subject: [GHC] #3637: ./configure doesn't understand Gentoo's
 build/host/target
In-Reply-To: <047.fcebd5e462086e021124f01f2c19fc8c@abbot.galois.com>
References: <047.fcebd5e462086e021124f01f2c19fc8c@abbot.galois.com>
Message-ID: <056.c269616b5faa5717c3d655b0b0886605@abbot.galois.com>

#3637: ./configure doesn't understand Gentoo's build/host/target
---------------------------------+------------------------------------------
    Reporter:  kolmodin          |        Owner:  igloo              
        Type:  merge             |       Status:  new                
    Priority:  high              |    Milestone:  6.12.2             
   Component:  Build System      |      Version:  6.12.1 RC1         
    Keywords:  regression        |   Difficulty:  Unknown            
          Os:  Unknown/Multiple  |     Testcase:                     
Architecture:  Unknown/Multiple  |      Failure:  Building GHC failed
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  => igloo
  * type:  bug => merge


Comment:

 Patch looks good to me; I committed it.

 {{{
 Tue Jan 19 02:28:19 PST 2010  Simon Marlow <marlowsd@gmail.com>
   * Allow GNU-standard --host, --build, --target configure options (#3637)
   Patch contributed by asuffield@suffields.me.uk
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3637#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 11:49:18 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 11:21:36 2010
Subject: [GHC] #3745: Non-deterministic behavior with FFI
In-Reply-To: <048.13932c70c5ac7d2182ef99747868ffe2@abbot.galois.com>
References: <048.13932c70c5ac7d2182ef99747868ffe2@abbot.galois.com>
Message-ID: <057.2599dc0989b6ed2e66963c470d89b926@abbot.galois.com>

#3745: Non-deterministic behavior with FFI
---------------------------------+------------------------------------------
    Reporter:  gchrupala         |        Owner:                             
        Type:  bug               |       Status:  new                        
    Priority:  normal            |    Milestone:  6.12.2                     
   Component:  Compiler (FFI)    |      Version:  6.10.4                     
    Keywords:                    |   Difficulty:                             
          Os:  Unknown/Multiple  |     Testcase:                             
Architecture:  Unknown/Multiple  |      Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------
Changes (by simonmar):

  * priority:  high => normal


Comment:

 dropping prio while we wait for feedback.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3745#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 12:11:25 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 11:43:40 2010
Subject: [GHC] #3828: Error in array index
In-Reply-To: <042.183a30ca9d84f0b1998a7b985bfd6d87@abbot.galois.com>
References: <042.183a30ca9d84f0b1998a7b985bfd6d87@abbot.galois.com>
Message-ID: <051.6ef55b617088d56b5604bb9a84cf6a82@abbot.galois.com>

#3828: Error in array index
-------------------------+--------------------------------------------------
    Reporter:  CBa       |        Owner:                    
        Type:  bug       |       Status:  new               
    Priority:  normal    |    Milestone:                    
   Component:  Compiler  |      Version:  6.12.1            
    Keywords:  sunos     |   Difficulty:                    
          Os:  Solaris   |     Testcase:                    
Architecture:  sparc     |      Failure:  Compile-time crash
-------------------------+--------------------------------------------------

Comment(by simonpj):

 Did you remove every single M.hi file lying around; ie started in a clean
 tree?  This kind of thing can happy when the binary format changes.
 (Later GHCs are more robust.)

 S

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3828#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 12:18:04 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 11:50:19 2010
Subject: [GHC] #3789: Segfault and -dstg-lint errors using FFI and
 -XEmptyDataDecls
In-Reply-To: <045.2c0f987a4ddd3ec0b9fa039bca72f39b@abbot.galois.com>
References: <045.2c0f987a4ddd3ec0b9fa039bca72f39b@abbot.galois.com>
Message-ID: <054.fe8a0a1050583155795bdd9425de3643@abbot.galois.com>

#3789: Segfault and -dstg-lint errors using FFI and -XEmptyDataDecls
-------------------------------+--------------------------------------------
    Reporter:  judahj          |        Owner:               
        Type:  bug             |       Status:  new          
    Priority:  high            |    Milestone:  6.12.2       
   Component:  Compiler (NCG)  |      Version:  6.12.1       
    Keywords:                  |   Difficulty:               
          Os:  MacOS X         |     Testcase:               
Architecture:  x86             |      Failure:  Runtime crash
-------------------------------+--------------------------------------------

Comment(by simonmar):

 Unable to reproduce the segfault on x86/Linux (Ubuntu 9.10) with either
 6.10.4 or 6.12.1.  Can anyone else reproduce it? Is it MacOS X only
 perhaps?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3789#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 13:43:42 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 13:15:59 2010
Subject: [GHC] #3794: Compiling a main program yields: /usr/bin/ld:
 cannot find -lHSrtsmain
In-Reply-To: <044.e1a190f33d758a6bb97e24503af072e1@abbot.galois.com>
References: <044.e1a190f33d758a6bb97e24503af072e1@abbot.galois.com>
Message-ID: <053.2786626491fc1863e00532fccc9e55ca@abbot.galois.com>

#3794: Compiling a main program yields: /usr/bin/ld: cannot find -lHSrtsmain
-----------------------------+----------------------------------------------
    Reporter:  guest         |        Owner:  igloo                
        Type:  bug           |       Status:  new                  
    Priority:  normal        |    Milestone:  6.12.2               
   Component:  Build System  |      Version:  6.12.1               
    Keywords:                |   Difficulty:                       
          Os:  Linux         |     Testcase:                       
Architecture:  x86           |      Failure:  Installing GHC failed
-----------------------------+----------------------------------------------

Comment(by guest):

 It seems to be important whether I run as root or whether I'm a regular
 user using sudo.
 The first one works, the latter one does not work.
 On Ubuntu it is standard to use sudo.

 {{{
 user@bla:/tmp/ghc-6.12.1> umask
 0077
 user@bla:/tmp/ghc-6.12.1> echo umask | sudo bash
 0022
 user@bla:/tmp> tar xfj /archive/ghc-6.12.1-i386-unknown-linux-n.tar.bz2
 user@bla:/tmp> cd ghc-6.12.1/
 user@bla:/tmp/ghc-6.12.1> ./configure
 checking for path to top of build tree... /tmp/ghc-6.12.1
 checking for perl... /usr/bin/perl
 checking if your perl works in shell scripts... yes
 checking for a BSD-compatible install... /usr/bin/install -c
 checking whether ln -s works... yes
 checking for ar... /usr/bin/ar
 checking whether /usr/bin/ar is GNU ar... yes
 checking for ar arguments... q
 checking for gcc... gcc
 checking for C compiler default output file name... a.out
 checking whether the C compiler works... yes
 checking whether we are cross compiling... no
 checking for suffix of executables...
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... yes
 checking whether gcc accepts -g... yes
 checking for gcc option to accept ISO C89... none needed
 checking whether ranlib is needed... no
 checking for sed... /bin/sed
 checking version of gcc... 4.3.3
 checking how to run the C preprocessor... gcc -E
 checking for extra options to pass gcc when compiling via C...  -fwrapv
 configure: creating ./config.status
 config.status: creating extra-gcc-opts
 config.status: creating mk/config.mk
 config.status: creating mk/install.mk
 ****************************************************
 Configuration done, ready to 'make install'
 (see README and INSTALL files for more info.)
 ****************************************************
 user@bla:/tmp/ghc-6.12.1> sudo make install
 ...
 user@bla:/tmp/ghc-6.12.1> ll /usr/local/lib/ghc-6.12.1/libHS*
 -rw-r--r-- 1 root root  102164 2010-01-19 19:33
 /usr/local/lib/ghc-6.12.1/libHSffi.a
 -rwxr-xr-x 1 root root   81578 2010-01-19 19:33 /usr/local/lib/ghc-6.12.1
 /libHSffi-ghc6.12.1.so
 -rw-r--r-- 1 root root  102164 2010-01-19 19:33
 /usr/local/lib/ghc-6.12.1/libHSffi_p.a
 -rw------- 1 root root  443834 2010-01-19 19:32
 /usr/local/lib/ghc-6.12.1/libHSrts.a
 -rw------- 1 root root 1604326 2010-01-19 19:32
 /usr/local/lib/ghc-6.12.1/libHSrts_debug.a
 -rwx------ 1 root root 1019476 2010-01-19 19:32 /usr/local/lib/ghc-6.12.1
 /libHSrts_debug-ghc6.12.1.so
 -rwx------ 1 root root  323893 2010-01-19 19:32 /usr/local/lib/ghc-6.12.1
 /libHSrts-ghc6.12.1.so
 -rw------- 1 root root  452792 2010-01-19 19:32
 /usr/local/lib/ghc-6.12.1/libHSrts_l.a
 -rw------- 1 root root    1026 2010-01-19 19:32
 /usr/local/lib/ghc-6.12.1/libHSrtsmain.a
 -rw------- 1 root root  527154 2010-01-19 19:32
 /usr/local/lib/ghc-6.12.1/libHSrts_p.a
 -rw------- 1 root root  515788 2010-01-19 19:32
 /usr/local/lib/ghc-6.12.1/libHSrts_thr.a
 -rw------- 1 root root 1872880 2010-01-19 19:32
 /usr/local/lib/ghc-6.12.1/libHSrts_thr_debug.a
 -rwx------ 1 root root 1189377 2010-01-19 19:32 /usr/local/lib/ghc-6.12.1
 /libHSrts_thr_debug-ghc6.12.1.so
 -rwx------ 1 root root  383150 2010-01-19 19:32 /usr/local/lib/ghc-6.12.1
 /libHSrts_thr-ghc6.12.1.so
 -rw------- 1 root root  526884 2010-01-19 19:32
 /usr/local/lib/ghc-6.12.1/libHSrts_thr_l.a
 -rw------- 1 root root  600860 2010-01-19 19:32
 /usr/local/lib/ghc-6.12.1/libHSrts_thr_p.a
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3794#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 13:56:36 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 13:28:57 2010
Subject: [GHC] #3829: GHC leaks memory when compiling many files
Message-ID: <045.39f8c05a1a27aec7ca785e89572f98be@abbot.galois.com>

#3829: GHC leaks memory when compiling many files
-------------------------------+--------------------------------------------
    Reporter:  maltem          |       Owner:                              
        Type:  bug             |      Status:  new                         
    Priority:  normal          |   Component:  Compiler                    
     Version:  6.12.1          |    Keywords:                              
          Os:  Linux           |    Testcase:                              
Architecture:  x86_64 (amd64)  |     Failure:  Compile-time performance bug
-------------------------------+--------------------------------------------
 Sorry for the rather imprecise bug report; also, I'm not sure if this is
 related to #3294 or #1334.


 {{{cabal install highlighting-kate-0.2.5.1 --enable-library-profiling
 --reinstall}}}

 On my machine, this takes a lot of memory: when passing 1.7G, I have to
 kill it. However, compilation of single modules from that package takes
 much fewer memory.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3829>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 15:12:37 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 14:45:20 2010
Subject: [GHC] #635: Replace use of select() in the I/O manager with
 epoll/kqueue/etc.
In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@abbot.galois.com>
References: <047.158ac52b7977b3e9f47680935a918275@abbot.galois.com>
Message-ID: <056.bb546ce9047b23e9f2a5e58b3e8c8450@abbot.galois.com>

#635: Replace use of select() in the I/O manager with epoll/kqueue/etc.
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  bos                       
        Type:  task              |       Status:  new                       
    Priority:  normal            |    Milestone:  _|_                       
   Component:  libraries/base    |      Version:  6.4.1                     
    Keywords:                    |   Difficulty:  Project (more than a week)
          Os:  Unknown/Multiple  |     Testcase:  N/A                       
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug   
---------------------------------+------------------------------------------

Comment(by tibbe):

 We've been working on a replacement for the I/O manager for a few weeks
 now. The latest code can be found at:

 http://github.com/tibbe/event

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/635#comment:28>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 15:51:45 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 15:24:19 2010
Subject: [GHC] #3741: ghci misinterprets "early" unicode characters
In-Reply-To: <044.258de514f09730ca65d032a50db6d67d@abbot.galois.com>
References: <044.258de514f09730ca65d032a50db6d67d@abbot.galois.com>
Message-ID: <053.853a2ca64852a02ee8aaed11c99997fa@abbot.galois.com>

#3741: ghci misinterprets "early" unicode characters
----------------------------------------+-----------------------------------
  Reporter:  brian                      |          Owner:  igloo           
      Type:  merge                      |         Status:  closed          
  Priority:  normal                     |      Milestone:  6.12.2          
 Component:  Compiler (Parser)          |        Version:  6.10.4          
Resolution:  fixed                      |       Keywords:                  
Difficulty:                             |             Os:  Unknown/Multiple
  Testcase:                             |   Architecture:  Unknown/Multiple
   Failure:  GHC rejects valid program  |  
----------------------------------------+-----------------------------------
Changes (by igloo):

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


Comment:

 Fixed in 6.12:
 {{{
 Tue Jan 19 19:55:30 GMT 2010  Ian Lynagh <igloo@earth.li>
   * Fix #3741
   This isn't exactly a merge of
       Thu Dec 10 16:09:09 GMT 2009  Simon Marlow <marlowsd@gmail.com>
         * Fix #3741, simplifying things in the process
   as it doesn't do any of the simplification, but it does fix the actual
   bug.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3741#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 16:42:04 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 16:14:23 2010
Subject: [GHC] #3745: Non-deterministic behavior with FFI
In-Reply-To: <048.13932c70c5ac7d2182ef99747868ffe2@abbot.galois.com>
References: <048.13932c70c5ac7d2182ef99747868ffe2@abbot.galois.com>
Message-ID: <057.c10fc62f090ab6eb4b4a023d228f807e@abbot.galois.com>

#3745: Non-deterministic behavior with FFI
---------------------------------+------------------------------------------
    Reporter:  gchrupala         |        Owner:                             
        Type:  bug               |       Status:  new                        
    Priority:  normal            |    Milestone:  6.12.2                     
   Component:  Compiler (FFI)    |      Version:  6.10.4                     
    Keywords:                    |   Difficulty:                             
          Os:  Unknown/Multiple  |     Testcase:                             
Architecture:  Unknown/Multiple  |      Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------

Comment(by gchrupala):

 Hi, thanks for looking into this.

 Replying to [comment:2 simonmar]:
 > I can't reproduce it here on my laptop (x86/Linux).  Some questions:
 >
 >  * can you make it happen on more than one machine? what platform(s)?

 I discovered the bug on x86_64/Linux. I have now tried it also on
 x86/Linux and Intel/Mac, and it doesn't happen on those two.

 >  * do you get different results when the program is compiled with
 `-debug`?

 No, same nondeterministic behavior.

 >  * does valgrind say anything?

 Valgrind reports no errors.

 >  * does it happen with 6.12.1?

 Just tried it, and the same problem is there with 6.12.1

 > Is it possible there's a memory error in the FFI code, or the C++ code?
 perhaps an off-by-one array size?

 I can't be 100% sure there is no subtle bug in the code but I checked
 carefully for the obvious ones.

 Best,
 --
 Grzegorz

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3745#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 19:23:03 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 18:55:20 2010
Subject: [GHC] #3789: Segfault and -dstg-lint errors using FFI and
 -XEmptyDataDecls
In-Reply-To: <045.2c0f987a4ddd3ec0b9fa039bca72f39b@abbot.galois.com>
References: <045.2c0f987a4ddd3ec0b9fa039bca72f39b@abbot.galois.com>
Message-ID: <054.49a5ccedb78e2b04b2f12fcb6a4008d1@abbot.galois.com>

#3789: Segfault and -dstg-lint errors using FFI and -XEmptyDataDecls
-------------------------------+--------------------------------------------
    Reporter:  judahj          |        Owner:               
        Type:  bug             |       Status:  new          
    Priority:  high            |    Milestone:  6.12.2       
   Component:  Compiler (NCG)  |      Version:  6.12.1       
    Keywords:                  |   Difficulty:               
          Os:  MacOS X         |     Testcase:               
Architecture:  x86             |      Failure:  Runtime crash
-------------------------------+--------------------------------------------

Comment(by igloo):

 I can't reproduce it on OS X here, but then I only have 10.5, and judahj
 says it only happens for him on 10.6.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3789#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 19 21:39:55 2010
From: trac at galois.com (GHC)
Date: Tue Jan 19 21:12:11 2010
Subject: [GHC] #3830: weird error message from type qualification mistake
Message-ID: <044.23fe3a11d72c99ed44053dd8b8acd26f@abbot.galois.com>

#3830: weird error message from type qualification mistake
-------------------------------+--------------------------------------------
    Reporter:  guest           |       Owner:                                   
        Type:  bug             |      Status:  new                              
    Priority:  normal          |   Component:  Compiler                         
     Version:  6.10.4          |    Keywords:                                   
          Os:  Linux           |    Testcase:                                   
Architecture:  x86_64 (amd64)  |     Failure:  Incorrect warning at compile-time
-------------------------------+--------------------------------------------
 {-# LANGUAGE GADTs, RankNTypes  #-}

 data Parity a where
   Odd :: Int -> forall a. Parity (Int,Int,a)


 (the "forall a" is in the wrong place) gives the error message

     Malformed constructor result type:
       forall a :: k_a3Gz. Parity (Int, Int, a)

 That k_a3Gz. is a little bit cryptic.

 --solrize

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3830>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 20 04:39:24 2010
From: trac at galois.com (GHC)
Date: Wed Jan 20 04:11:40 2010
Subject: [GHC] #3745: Non-deterministic behavior with FFI
In-Reply-To: <048.13932c70c5ac7d2182ef99747868ffe2@abbot.galois.com>
References: <048.13932c70c5ac7d2182ef99747868ffe2@abbot.galois.com>
Message-ID: <057.4f1dbed42e52afd8614c1a989539752e@abbot.galois.com>

#3745: Non-deterministic behavior with FFI
---------------------------------+------------------------------------------
    Reporter:  gchrupala         |        Owner:                             
        Type:  bug               |       Status:  new                        
    Priority:  high              |    Milestone:  6.12.2                     
   Component:  Compiler (FFI)    |      Version:  6.10.4                     
    Keywords:                    |   Difficulty:                             
          Os:  Unknown/Multiple  |     Testcase:                             
Architecture:  x86_64 (amd64)    |      Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------
Changes (by simonmar):

  * priority:  normal => high
  * architecture:  Unknown/Multiple => x86_64 (amd64)


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3745#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 20 04:53:16 2010
From: trac at galois.com (GHC)
Date: Wed Jan 20 04:25:34 2010
Subject: [GHC] #3813: Invalid warning from GHCi
In-Reply-To: <051.207c96ece971d6767ecb4b1e779ba7b2@abbot.galois.com>
References: <051.207c96ece971d6767ecb4b1e779ba7b2@abbot.galois.com>
Message-ID: <060.7f158db49c5cc49e1c06198d2918dfd6@abbot.galois.com>

#3813: Invalid warning from GHCi
---------------------------------+------------------------------------------
    Reporter:  NeilMitchell      |        Owner:  igloo                            
        Type:  bug               |       Status:  new                              
    Priority:  normal            |    Milestone:  6.12.2                           
   Component:  GHCi              |      Version:  6.10.4                           
    Keywords:                    |   Difficulty:                                   
          Os:  Unknown/Multiple  |     Testcase:                                   
Architecture:  Unknown/Multiple  |      Failure:  Incorrect warning at compile-time
---------------------------------+------------------------------------------
Changes (by simonpj):

  * owner:  simonpj => igloo


Comment:

 Thanks for the report.  Fixed by
 {{{
 Wed Jan 20 09:45:33 GMT 2010  simonpj@microsoft.com
   * Fix Trac #3813: unused variables in GHCi bindings

   In a GHCi stmt we don't want to report unused variables,
   because we don't know the scope of the binding, eg

         Prelude> x <- blah

   Fixing this needed a little more info about the context of the stmt,
   thus the new constructor GhciStmt in the HsStmtContext type.

     M ./compiler/deSugar/DsExpr.lhs +3
     M ./compiler/deSugar/DsMeta.hs -7 +13
     M ./compiler/hsSyn/HsExpr.lhs -1 +4
     M ./compiler/rename/RnEnv.lhs -1
     M ./compiler/rename/RnPat.lhs -5 +13
     M ./compiler/typecheck/TcMatches.lhs -2 +1
     M ./compiler/typecheck/TcRnDriver.lhs -3 +3
 }}}
 Ian is going to add a test, then close.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3813#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 20 04:54:53 2010
From: trac at galois.com (GHC)
Date: Wed Jan 20 04:27:09 2010
Subject: [GHC] #3823: GHC 6.12 breaks combination of records and
 mutually recursive modules
In-Reply-To: <044.7cc1ab77124bd237b37d840aa7398830@abbot.galois.com>
References: <044.7cc1ab77124bd237b37d840aa7398830@abbot.galois.com>
Message-ID: <053.c2ebf758032bc8a766d3fbdaf31626ac@abbot.galois.com>

#3823: GHC 6.12 breaks combination of records and mutually recursive modules
---------------------------------+------------------------------------------
    Reporter:  mboes             |        Owner:  igloo                    
        Type:  merge             |       Status:  new                      
    Priority:  high              |    Milestone:  6.12.2                   
   Component:  Compiler          |      Version:  6.12.1                   
    Keywords:                    |   Difficulty:                           
          Os:  Unknown/Multiple  |     Testcase:                           
Architecture:  Unknown/Multiple  |      Failure:  GHC rejects valid program
---------------------------------+------------------------------------------
Changes (by simonpj):

  * owner:  simonpj => igloo
  * type:  bug => merge


Comment:

 Good catch, thank you!  Easily fixed too
 {{{
 Wed Jan 20 09:42:21 GMT 2010  simonpj@microsoft.com
   * Fix Trac #3823, plus warning police in TcRnDriver

   The immediate reason for this patch is to fix #3823. This was
   rather easy: all the work was being done but I was returning
   type_env2 rather than type_env3.

   An unused-veriable warning would have shown this up, so I fixed all
   the other warnings in TcRnDriver.  Doing so showed up at least two
   genuine lurking bugs.  Hurrah.

     M ./compiler/typecheck/TcRnDriver.lhs -54 +60
     M ./compiler/typecheck/TcTyClsDecls.lhs -2 +2
 }}}
 This is worth merging to the 6.12 branch, Ian.  And adding a regression
 test.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3823#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 20 05:17:08 2010
From: trac at galois.com (GHC)
Date: Wed Jan 20 04:49:20 2010
Subject: [GHC] #3828: Error in array index
In-Reply-To: <042.183a30ca9d84f0b1998a7b985bfd6d87@abbot.galois.com>
References: <042.183a30ca9d84f0b1998a7b985bfd6d87@abbot.galois.com>
Message-ID: <051.8a7345652dd0f1e3d39e29dc3104e42f@abbot.galois.com>

#3828: Error in array index
-------------------------+--------------------------------------------------
    Reporter:  CBa       |        Owner:                    
        Type:  bug       |       Status:  new               
    Priority:  normal    |    Milestone:                    
   Component:  Compiler  |      Version:  6.12.1            
    Keywords:  sunos     |   Difficulty:                    
          Os:  Solaris   |     Testcase:                    
Architecture:  sparc     |      Failure:  Compile-time crash
-------------------------+--------------------------------------------------

Comment(by CBa):

 I stopped only once after configure & make to fix mkDerivedConstants.c
 (there is
 another ticket). Ticket #3827 reports exactly the same error on
 linux/powerpc.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3828#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 20 06:45:28 2010
From: trac at galois.com (GHC)
Date: Wed Jan 20 06:17:45 2010
Subject: [GHC] #3830: weird error message from type qualification mistake
In-Reply-To: <044.23fe3a11d72c99ed44053dd8b8acd26f@abbot.galois.com>
References: <044.23fe3a11d72c99ed44053dd8b8acd26f@abbot.galois.com>
Message-ID: <053.a3ad203939007009bccdc8615d1024f1@abbot.galois.com>

#3830: weird error message from type qualification mistake
------------------------------------------------+---------------------------
  Reporter:  guest                              |          Owner:                
      Type:  bug                                |         Status:  closed        
  Priority:  normal                             |      Milestone:                
 Component:  Compiler                           |        Version:  6.10.4        
Resolution:  fixed                              |       Keywords:                
Difficulty:                                     |             Os:  Linux         
  Testcase:                                     |   Architecture:  x86_64 (amd64)
   Failure:  Incorrect warning at compile-time  |  
------------------------------------------------+---------------------------
Changes (by simonpj):

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


Old description:

> {-# LANGUAGE GADTs, RankNTypes  #-}
>
> data Parity a where
>   Odd :: Int -> forall a. Parity (Int,Int,a)
>

> (the "forall a" is in the wrong place) gives the error message
>
>     Malformed constructor result type:
>       forall a :: k_a3Gz. Parity (Int, Int, a)
>
> That k_a3Gz. is a little bit cryptic.
>
> --solrize

New description:

 {{{
 {-# LANGUAGE GADTs, RankNTypes  #-}

 data Parity a where
   Odd :: Int -> forall a. Parity (Int,Int,a)
 }}}

 (the "forall a" is in the wrong place) gives the error message
 {{{
     Malformed constructor result type:
       forall a :: k_a3Gz. Parity (Int, Int, a)
 }}}
 That k_a3Gz. is a little bit cryptic.

 --solrize

--

Comment:

 Good point. The message from 6.12 is better
 {{{
 T3830.hs:4:3:
     Data constructor `Odd' returns type `forall a.
                                          Parity (Int, Int, a)'
       instead of an instance of its parent type `Parity a'
     In the definition of data constructor `Odd'
     In the data type declaration for `Parity'
 }}}
 Nevertheless, I also added a little more info to `HsTyVarBndr` to prevent
 this kind of thing happening again.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3830#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 20 08:00:46 2010
From: trac at galois.com (GHC)
Date: Wed Jan 20 07:33:00 2010
Subject: [GHC] #3799: undefined symbols and undefined references
 possibly related to template haskell
In-Reply-To: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
References: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
Message-ID: <058.e07c83392783d673749df53773bd0fc6@abbot.galois.com>

#3799: undefined symbols and undefined references possibly related to template
haskell
---------------------------------+------------------------------------------
  Reporter:  JeremyShaw          |          Owner:                                               
      Type:  bug                 |         Status:  closed                                       
  Priority:  normal              |      Milestone:  6.12.2                                       
 Component:  Compiler            |        Version:  6.13                                         
Resolution:  invalid             |       Keywords:  undefined symbols references template haskell
Difficulty:                      |             Os:  Unknown/Multiple                             
  Testcase:                      |   Architecture:  Unknown/Multiple                             
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------

Comment(by Saizan):

 just for clarification: only recently haddock started building to object
 code and so triggering this bug, right?
 Since the common case has always been calling cabal haddock just after
 cabal build and it used to work correctly.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 20 08:05:58 2010
From: trac at galois.com (GHC)
Date: Wed Jan 20 07:38:13 2010
Subject: [GHC] #3831: GHC uses too much memory compiling terminfo
Message-ID: <044.5fe60f4f535f1251caca48895d45a780@abbot.galois.com>

#3831: GHC uses too much memory compiling terminfo
---------------------------------+------------------------------------------
    Reporter:  igloo             |        Owner:                              
        Type:  bug               |       Status:  new                         
    Priority:  high              |    Milestone:  6.12.2                      
   Component:  Compiler          |      Version:  6.12.1                      
    Keywords:                    |   Difficulty:                              
          Os:  Unknown/Multiple  |     Testcase:                              
Architecture:  Unknown/Multiple  |      Failure:  Compile-time performance bug
---------------------------------+------------------------------------------
 On x86/Linux, with this `mk/build.mk`:
 {{{
 GhcLibWays = v p dyn
 SRC_HC_OPTS     = -O -H64m -Rghc-timing
 GhcStage1HcOpts = -O -fasm
 GhcStage2HcOpts = -O2 -fasm
 GhcHcOpts       = -Rghc-timing
 GhcLibHcOpts    = -O2 -XGenerics

 #SplitObjs          = YES
 SplitObjs          = NO
 HADDOCK_DOCS       = NO
 BUILD_DOCBOOK_HTML = NO
 BUILD_DOCBOOK_PS   = NO
 BUILD_DOCBOOK_PDF  = NO

 #
 -----------------------------------------------------------------------------
 # Other settings that might be useful

 # profiled RTS
 #GhcRtsCcOpts =  -pg -g

 # Optimised/profiled RTS
 #GhcRtsCcOpts = -O2 -pg

 #GhcRtsWithFrontPanel = YES
 #SRC_HC_OPTS += `gtk-config --libs`

 # NoFib settings
 NoFibWays =
 STRIP=:
 }}}
 and these commands:
 {{{
 $ sh boot
 $ ./configure --prefix=/opt/ghc-6.13
 $ make
 }}}
 and a 1GB memory limit (`ulimit -v 1024000`), the build fails with:
 {{{
 "inplace/bin/ghc-stage1"   -O -H64m -Rghc-timing    -package-name
 terminfo-0.3.1.1 -hide-all-packages -i -ilibraries/terminfo/.
 -ilibraries/terminfo/dist-install/build -ilibraries/terminfo/dist-
 install/build/autogen -Ilibraries/terminfo/dist-install/build
 -Ilibraries/terminfo/dist-install/build/autogen -Ilibraries/terminfo/.
 -optP-include -optPlibraries/terminfo/dist-
 install/build/autogen/cabal_macros.h -package base-4.2.0.0 -package
 extensible-exceptions-0.1.1.1  -Wall -XForeignFunctionInterface
 -XDeriveDataTypeable -XEmptyDataDecls -XScopedTypeVariables
 -XFlexibleInstances -O2 -XGenerics -fno-warn-deprecated-flags     -odir
 libraries/terminfo/dist-install/build -hidir libraries/terminfo/dist-
 install/build -stubdir libraries/terminfo/dist-install/build -hisuf hi
 -osuf  o -hcsuf hc -c
 libraries/terminfo/./System/Console/Terminfo/Effects.hs -o
 libraries/terminfo/dist-install/build/System/Console/Terminfo/Effects.o
 ghc-stage1: out of memory (requested 1048576 bytes)
 make[1]: *** [libraries/terminfo/dist-
 install/build/System/Console/Terminfo/Effects.o] Error 1
 make: *** [all] Error 2
 }}}
 With `-v`:
 {{{
 Glasgow Haskell Compiler, Version 6.13.20100120, for Haskell 98, stage 1
 booted
 by GHC version 6.8.2
 Using binary package database:
 /home/ian/qq/ghc/inplace/lib/package.conf.d/packa
 ge.cache
 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-inplace
 wired-in package integer-gmp mapped to integer-gmp-0.2.0.0-inplace
 wired-in package base mapped to base-4.2.0.0-inplace
 wired-in package rts mapped to builtin_rts
 wired-in package haskell98 mapped to haskell98-1.0.1.1-inplace
 wired-in package template-haskell mapped to template-
 haskell-2.4.0.0-inplace
 wired-in package dph-seq mapped to dph-seq-0.4.0-inplace
 wired-in package dph-par mapped to dph-par-0.4.0-inplace
 Hsc static flags: -static
 Created temporary directory: /tmp/ghc1791_0
 *** Checking old interface for
 terminfo-0.3.1.1:System.Console.Terminfo.Effects:
 *** Parser:
 *** Renamer/typechecker:
 *** Desugar:
     Result size = 1076
 *** Simplifier gentle[rules,no inline] max-iterations=4:
     Result size = 802
     Result size = 758
     Result size = 758
 *** Specialise:
     Result size = 758
 *** Float out(not lambdas, constants):
     Result size = 826
 *** Float inwards:
     Result size = 826
 *** Simplifier Phase 2 [main] max-iterations=4:
     Result size = 1499
     Result size = 2190
     Result size = 2994
     Result size = 2380
     Result size = 2380
 *** Simplifier Phase 1 [main] max-iterations=4:
     Result size = 2145
     Result size = 2115
 *** Simplifier Phase 0 [main] max-iterations=4:
     Result size = 2115
 *** Demand analysis:
     Result size = 2115
 *** Worker Wrapper binds:
     Result size = 2115
 *** Glom binds:
 *** GlomBinds:
     Result size = 2115
 *** Simplifier Phase 0 [post-worker-wrapper] max-iterations=4:
     Result size = 2115
 *** Float out(not lambdas, constants):
     Result size = 2121
 *** Common sub-expression:
     Result size = 2102
 *** Float inwards:
     Result size = 2102
 *** Liberate case:
     Result size = 2102
 *** Simplifier Phase 0 [post-liberate-case] max-iterations=4:
     Result size = 2082
     Result size = 2082
 *** SpecConstr:
 ghc-stage1: out of memory (requested 1048576 bytes)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3831>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 20 08:11:09 2010
From: trac at galois.com (GHC)
Date: Wed Jan 20 07:43:23 2010
Subject: [GHC] #3831: GHC uses too much memory compiling terminfo
In-Reply-To: <044.5fe60f4f535f1251caca48895d45a780@abbot.galois.com>
References: <044.5fe60f4f535f1251caca48895d45a780@abbot.galois.com>
Message-ID: <053.381d41ceca05b1b9cc079b54dd0b02fe@abbot.galois.com>

#3831: GHC uses too much memory compiling terminfo
---------------------------------+------------------------------------------
    Reporter:  igloo             |        Owner:                              
        Type:  bug               |       Status:  new                         
    Priority:  high              |    Milestone:  6.12.2                      
   Component:  Compiler          |      Version:  6.13                        
    Keywords:                    |   Difficulty:                              
          Os:  Unknown/Multiple  |     Testcase:                              
Architecture:  Unknown/Multiple  |      Failure:  Compile-time performance bug
---------------------------------+------------------------------------------
Changes (by igloo):

  * version:  6.12.1 => 6.13


Comment:

 This was compiling the HEAD; 6.12 not tested.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3831#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 20 09:14:36 2010
From: trac at galois.com (GHC)
Date: Wed Jan 20 08:46:48 2010
Subject: [GHC] #3832: openTempFile does not apply an encoding to the stream
Message-ID: <043.a33d89094ea9d4373ff283879f5793a6@abbot.galois.com>

#3832: openTempFile does not apply an encoding to the stream
---------------------------------+------------------------------------------
    Reporter:  ross              |       Owner:                
        Type:  bug               |      Status:  new           
    Priority:  normal            |   Component:  libraries/base
     Version:  6.12.1            |    Keywords:                
          Os:  Unknown/Multiple  |    Testcase:                
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown  
---------------------------------+------------------------------------------
 In the following program, the output is written as a raw byte, even in a
 UTF locale:
 {{{
 module Main where

 import System.IO

 main = do
         (_, h) <- openTempFile "." "test.txt"
         hPutStrLn h $ "\xa9" -- Copyright symbol
         hClose h
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3832>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 20 10:35:12 2010
From: trac at galois.com (GHC)
Date: Wed Jan 20 10:07:25 2010
Subject: [GHC] #3794: Compiling a main program yields: /usr/bin/ld:
 cannot find -lHSrtsmain
In-Reply-To: <044.e1a190f33d758a6bb97e24503af072e1@abbot.galois.com>
References: <044.e1a190f33d758a6bb97e24503af072e1@abbot.galois.com>
Message-ID: <053.ac0d1e8c8f930d70b98d6db6440f79ee@abbot.galois.com>

#3794: Compiling a main program yields: /usr/bin/ld: cannot find -lHSrtsmain
------------------------------------+---------------------------------------
  Reporter:  guest                  |          Owner:  igloo 
      Type:  bug                    |         Status:  closed
  Priority:  normal                 |      Milestone:  6.12.2
 Component:  Build System           |        Version:  6.12.1
Resolution:  fixed                  |       Keywords:        
Difficulty:                         |             Os:  Linux 
  Testcase:                         |   Architecture:  x86   
   Failure:  Installing GHC failed  |  
------------------------------------+---------------------------------------
Changes (by igloo):

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


Comment:

 OK, I still can't reproduce it (I think your umask must be getting changed
 when you sudo), but I think I see the problem: We were installing the
 files with `cp`, rather than `install -m ...`. Fixed by:
 {{{
 Tue Jan 19 23:26:23 GMT 2010  Ian Lynagh <igloo@earth.li>
   * Change how RTS libraries get installed; fixes trac #3794
 }}}
 in HEAD and 6.12.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3794#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 20 13:21:23 2010
From: trac at galois.com (GHC)
Date: Wed Jan 20 12:53:42 2010
Subject: [GHC] #3833: Panic on standlone deriving without
 GeneralizedNewtypeDeriving
Message-ID: <048.153c3186ee473f8a009c1a2b45f3c459@abbot.galois.com>

#3833: Panic on standlone deriving without GeneralizedNewtypeDeriving
---------------------------------+------------------------------------------
    Reporter:  Khudyakov         |       Owner:                    
        Type:  bug               |      Status:  new               
    Priority:  normal            |   Component:  Compiler          
     Version:  6.12.1            |    Keywords:                    
          Os:  Unknown/Multiple  |    Testcase:                    
Architecture:  Unknown/Multiple  |     Failure:  Compile-time crash
---------------------------------+------------------------------------------
 I found that GHC panics on the following program if
 GeneralizedNewtypeDeriving pragma is removed. Otherwise it works just
 fine.

 {{{
 {-# LANGUAGE StandaloneDeriving #-}
 {-# LANGUAGE GeneralizedNewtypeDeriving #-} -- Removal causes crash
 import Data.Monoid

 newtype DecodeMap e = DecodeMap [e]

 deriving instance Monoid (DecodeMap e)
 }}}

 Here is error message it produce
 {{{
 ghc: panic! (the 'impossible' happened)
   (GHC version 6.12.1 for i386-unknown-linux):
         genDerivBinds: bad derived class base:Data.Monoid.Monoid{tc rha}

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
 }}}

 This bug appears only in GHC6.12.1. GHC6.10.4 rightfully complain that I
 should enable GeneralizedNewtypeDeriving unstead of crashing.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3833>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 20 15:05:18 2010
From: trac at galois.com (GHC)
Date: Wed Jan 20 14:37:36 2010
Subject: [GHC] #3832: openTempFile does not apply an encoding to the
 stream
In-Reply-To: <043.a33d89094ea9d4373ff283879f5793a6@abbot.galois.com>
References: <043.a33d89094ea9d4373ff283879f5793a6@abbot.galois.com>
Message-ID: <052.8fa07783d18f5bb0737880d33b1f9222@abbot.galois.com>

#3832: openTempFile does not apply an encoding to the stream
---------------------------------+------------------------------------------
    Reporter:  ross              |        Owner:  simonmar    
        Type:  bug               |       Status:  assigned    
    Priority:  high              |    Milestone:  6.12.2      
   Component:  libraries/base    |      Version:  6.12.1      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar
  * priority:  normal => high
  * status:  new => assigned
  * milestone:  => 6.12.2


Comment:

 Well spotted, thanks for the report.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3832#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 20 20:25:54 2010
From: trac at galois.com (GHC)
Date: Wed Jan 20 19:58:06 2010
Subject: [GHC] #3834: Standalone deriving of an unsupported class panics GHC
Message-ID: <047.44a3c7a191ed906d7f7ef54a77a3dfad@abbot.galois.com>

#3834: Standalone deriving of an unsupported class panics GHC
---------------------------------+------------------------------------------
    Reporter:  diatchki          |       Owner:                    
        Type:  bug               |      Status:  new               
    Priority:  normal            |   Component:  Compiler          
     Version:  6.12.1            |    Keywords:                    
          Os:  Unknown/Multiple  |    Testcase:                    
Architecture:  Unknown/Multiple  |     Failure:  Compile-time crash
---------------------------------+------------------------------------------
 Using standalone deriving on a non-standard class, without
 GeneralizedNewtypeDeriving, causes GHC to panic.  Here is an example:

 {{{
 {-# LANGUAGE StandaloneDeriving #-}

 class C a
 instance C Int

 newtype T = T Int
 deriving instance C T

 Output:
 ghc: panic! (the 'impossible' happened)
   (GHC version 6.12.1 for x86_64-unknown-linux):
         genDerivBinds: bad derived class main:Main.C{tc rdh}
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3834>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 21 03:53:08 2010
From: trac at galois.com (GHC)
Date: Thu Jan 21 03:25:20 2010
Subject: [GHC] #3834: Standalone deriving of an unsupported class panics
 GHC
In-Reply-To: <047.44a3c7a191ed906d7f7ef54a77a3dfad@abbot.galois.com>
References: <047.44a3c7a191ed906d7f7ef54a77a3dfad@abbot.galois.com>
Message-ID: <056.4cc8fe6c0a6b36ad2ef3988f5c0700b9@abbot.galois.com>

#3834: Standalone deriving of an unsupported class panics GHC
---------------------------------+------------------------------------------
    Reporter:  diatchki          |        Owner:                    
        Type:  bug               |       Status:  new               
    Priority:  normal            |    Milestone:                    
   Component:  Compiler          |      Version:  6.12.1            
    Keywords:                    |   Difficulty:                    
          Os:  Unknown/Multiple  |     Testcase:                    
Architecture:  Unknown/Multiple  |      Failure:  Compile-time crash
---------------------------------+------------------------------------------

Comment(by simonpj):

 This looks like a dup of #3833, which itself was reported only yesterday
 by coincidence.  I'll leave open for now so that I test the fix on both
 cases.

 S

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3834#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 21 06:41:58 2010
From: trac at galois.com (GHC)
Date: Thu Jan 21 06:14:12 2010
Subject: [GHC] #3833: Panic on standlone deriving without
 GeneralizedNewtypeDeriving
In-Reply-To: <048.153c3186ee473f8a009c1a2b45f3c459@abbot.galois.com>
References: <048.153c3186ee473f8a009c1a2b45f3c459@abbot.galois.com>
Message-ID: <057.84af9afd5ba318040ecfdc930d84f953@abbot.galois.com>

#3833: Panic on standlone deriving without GeneralizedNewtypeDeriving
---------------------------------+------------------------------------------
    Reporter:  Khudyakov         |        Owner:  igloo             
        Type:  bug               |       Status:  new               
    Priority:  normal            |    Milestone:                    
   Component:  Compiler          |      Version:  6.12.1            
    Keywords:                    |   Difficulty:                    
          Os:  Unknown/Multiple  |     Testcase:                    
Architecture:  Unknown/Multiple  |      Failure:  Compile-time crash
---------------------------------+------------------------------------------
Changes (by simonpj):

  * owner:  => igloo


Comment:

 It turns out that the patch
 {{{
 Mon Dec  7 13:08:50 GMT 2009  simonpj@microsoft.com
   * Tidy up deriving error messages
 }}}
 on the HEAD fixes the problem.

 Attached is a 6.12-specific version of the patch.  I have not applied it
 because it causes a dozen test to have slightly different error message
 output.

 Ian, could you
  * Apply the patch to the branch
  * Accept the error message wibbles (if in doubt ask me)
  * Add a test to the HEAD regression suite
  * Close this and #3834

 Thanks

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3833#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 21 07:03:18 2010
From: trac at galois.com (GHC)
Date: Thu Jan 21 06:35:28 2010
Subject: [GHC] #3680: Improve docs for 'length'
In-Reply-To: <056.32b26bd2c9b5e88047fb0bedd9442617@abbot.galois.com>
References: <056.32b26bd2c9b5e88047fb0bedd9442617@abbot.galois.com>
Message-ID: <065.9afb381c25b2235eb465e0446768cec7@abbot.galois.com>

#3680: Improve docs for 'length'
----------------------------------+-----------------------------------------
    Reporter:  daniel.is.fischer  |        Owner:                   
        Type:  feature request    |       Status:  new              
    Priority:  high               |    Milestone:  6.12.2           
   Component:  libraries/base     |      Version:  6.10.4           
    Keywords:                     |   Difficulty:                   
          Os:  Unknown/Multiple   |     Testcase:                   
Architecture:  Unknown/Multiple   |      Failure:  Documentation bug
----------------------------------+-----------------------------------------
Changes (by simonpj):

  * priority:  normal => high


Comment:

 Easy to do; so high prio.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3680#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 21 10:04:09 2010
From: trac at galois.com (GHC)
Date: Thu Jan 21 09:36:23 2010
Subject: [GHC] #3821: Trace.Hpc.Reflect.examineTix segfaults on 64bit
In-Reply-To: <053.fbf59e92eb99357652de0927fec4376a@abbot.galois.com>
References: <053.fbf59e92eb99357652de0927fec4376a@abbot.galois.com>
Message-ID: <062.606a2875ccb019f0070c5d1878b5a780@abbot.galois.com>

#3821: Trace.Hpc.Reflect.examineTix segfaults on 64bit
---------------------------------+------------------------------------------
    Reporter:  TristanAllwood    |        Owner:  simonmar    
        Type:  bug               |       Status:  assigned    
    Priority:  high              |    Milestone:  6.12.2      
   Component:  Code Coverage     |      Version:  6.12.1      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  x86_64 (amd64)    |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  andy@? => simonmar
  * status:  new => assigned


Comment:

 I've validating.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3821#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 21 10:19:02 2010
From: trac at galois.com (GHC)
Date: Thu Jan 21 09:51:12 2010
Subject: [GHC] #3800: sizeofByteArray# returns allocated words,
 not requested length in bytes
In-Reply-To: <052.ddae457e72f5875b2acee6868c0b8060@abbot.galois.com>
References: <052.ddae457e72f5875b2acee6868c0b8060@abbot.galois.com>
Message-ID: <061.8fdf94896c33dcd1b124e8c45629d39b@abbot.galois.com>

#3800: sizeofByteArray# returns allocated words, not requested length in bytes
---------------------------------+------------------------------------------
    Reporter:  AntoineLatter     |        Owner:  igloo                      
        Type:  bug               |       Status:  new                        
    Priority:  high              |    Milestone:  6.12.2                     
   Component:  Compiler          |      Version:  6.12.1                     
    Keywords:                    |   Difficulty:                             
          Os:  Unknown/Multiple  |     Testcase:                             
Architecture:  Unknown/Multiple  |      Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * milestone:  6.14.1 => 6.12.2


Comment:

 This patch fixes the docs for 6.12.2, Ian could you merge please, and then
 milestone back to 6.14.1?

 {{{
 Tue Jan 19 10:38:25 GMT 2010  Simon Marlow <marlowsd@gmail.com>
   * Fix docs for sizeofByteArray#/sizeofMutableByteArray# (#3800)
   In 6.14.1 we'll switch these primops to return the exact byte size,
   but for 6.12.2 we need to fix the docs.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3800#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 21 10:20:12 2010
From: trac at galois.com (GHC)
Date: Thu Jan 21 09:52:24 2010
Subject: [GHC] #3832: openTempFile does not apply an encoding to the
 stream
In-Reply-To: <043.a33d89094ea9d4373ff283879f5793a6@abbot.galois.com>
References: <043.a33d89094ea9d4373ff283879f5793a6@abbot.galois.com>
Message-ID: <052.00104c187c9c4ee47dde24b01ba3d8f5@abbot.galois.com>

#3832: openTempFile does not apply an encoding to the stream
---------------------------------+------------------------------------------
    Reporter:  ross              |        Owner:  igloo       
        Type:  merge             |       Status:  new         
    Priority:  high              |    Milestone:  6.12.2      
   Component:  libraries/base    |      Version:  6.12.1      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * status:  assigned => new
  * type:  bug => merge


Comment:

 Fixed:

 {{{
 Wed Jan 20 21:18:30 GMT 2010  Simon Marlow <marlowsd@gmail.com>
   * fix #3832: use the locale encoding in openTempFile
   Also while I was here fix an XXX: the Handle contained an
   uninformative string like <fd: 4> for error messages rather than the
   real file path.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3832#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 21 13:20:56 2010
From: trac at galois.com (GHC)
Date: Thu Jan 21 12:53:12 2010
Subject: [GHC] #3800: sizeofByteArray# returns allocated words,
 not requested length in bytes
In-Reply-To: <052.ddae457e72f5875b2acee6868c0b8060@abbot.galois.com>
References: <052.ddae457e72f5875b2acee6868c0b8060@abbot.galois.com>
Message-ID: <061.fe58093e20809538c928b24a6d77680d@abbot.galois.com>

#3800: sizeofByteArray# returns allocated words, not requested length in bytes
---------------------------------+------------------------------------------
    Reporter:  AntoineLatter     |        Owner:  igloo                      
        Type:  bug               |       Status:  new                        
    Priority:  high              |    Milestone:  6.14.1                     
   Component:  Compiler          |      Version:  6.12.1                     
    Keywords:                    |   Difficulty:                             
          Os:  Unknown/Multiple  |     Testcase:                             
Architecture:  Unknown/Multiple  |      Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  6.12.2 => 6.14.1


Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3800#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 05:39:19 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 05:11:27 2010
Subject: [GHC] #3803: addCoverageTicksTobind should not panic when file
 location is Nothing
In-Reply-To: <046.170aea52f7935907ca6deb8869a6f4be@abbot.galois.com>
References: <046.170aea52f7935907ca6deb8869a6f4be@abbot.galois.com>
Message-ID: <055.a2814b6b2fcda72fd1a24d4ace1e3a37@abbot.galois.com>

#3803: addCoverageTicksTobind should not panic when file location is Nothing
---------------------------------+------------------------------------------
    Reporter:  clemens           |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  high              |    Milestone:  6.12.2      
   Component:  Compiler          |      Version:  6.12.1      
    Keywords:  hpc               |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by simonmar):

  * priority:  normal => high


Comment:

 easy to fix, so bump prio.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3803#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 05:46:51 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 05:19:00 2010
Subject: [GHC] #3793: System.Time.toClockTime does not support all valid
 timezone offsets.
In-Reply-To: <045.573376566b5efc770151c67d8f432e86@abbot.galois.com>
References: <045.573376566b5efc770151c67d8f432e86@abbot.galois.com>
Message-ID: <054.71b71824e5d8870c01f8de34c06f9822@abbot.galois.com>

#3793: System.Time.toClockTime does not support all valid timezone offsets.
----------------------------------------+-----------------------------------
    Reporter:  daniel                   |        Owner:                             
        Type:  bug                      |       Status:  new                        
    Priority:  high                     |    Milestone:  6.12.2                     
   Component:  libraries/old-time       |      Version:                             
    Keywords:  tz timezone toClockTime  |   Difficulty:  Easy (less than 1 hour)    
          Os:  Unknown/Multiple         |     Testcase:                             
Architecture:  Unknown/Multiple         |      Failure:  Incorrect result at runtime
----------------------------------------+-----------------------------------
Changes (by simonmar):

  * priority:  normal => high


Comment:

 we have a patch; make it high prio

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3793#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 06:40:28 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 06:12:46 2010
Subject: [GHC] #2615: ghci doesn't play nice with linker scripts
In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@abbot.galois.com>
References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@abbot.galois.com>
Message-ID: <060.2b78c509debca1a6e936b94ed6cf24e3@abbot.galois.com>

#2615: ghci doesn't play nice with linker scripts
------------------------------------------+---------------------------------
  Reporter:  AlecBerryman                 |          Owner:  igloo                  
      Type:  bug                          |         Status:  closed                 
  Priority:  normal                       |      Milestone:  6.14.1                 
 Component:  GHCi                         |        Version:  6.10.1                 
Resolution:  fixed                        |       Keywords:  dlopen, dynamic linking
Difficulty:  Unknown                      |             Os:  Linux                  
  Testcase:                               |   Architecture:  Unknown/Multiple       
   Failure:  Incorrect result at runtime  |  
------------------------------------------+---------------------------------
Changes (by igloo):

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


Comment:

 Done.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2615#comment:21>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 07:24:42 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 06:56:49 2010
Subject: [GHC] #3832: openTempFile does not apply an encoding to the
 stream
In-Reply-To: <043.a33d89094ea9d4373ff283879f5793a6@abbot.galois.com>
References: <043.a33d89094ea9d4373ff283879f5793a6@abbot.galois.com>
Message-ID: <052.1b61f0e68c9c61cb48e50bd6e5f5fee5@abbot.galois.com>

#3832: openTempFile does not apply an encoding to the stream
-----------------------------+----------------------------------------------
  Reporter:  ross            |          Owner:  igloo           
      Type:  merge           |         Status:  closed          
  Priority:  high            |      Milestone:  6.12.2          
 Component:  libraries/base  |        Version:  6.12.1          
Resolution:  fixed           |       Keywords:                  
Difficulty:                  |             Os:  Unknown/Multiple
  Testcase:                  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown    |  
-----------------------------+----------------------------------------------
Changes (by igloo):

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


Comment:

 Merged.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3832#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 07:25:03 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 06:58:37 2010
Subject: [GHC] #3637: ./configure doesn't understand Gentoo's
 build/host/target
In-Reply-To: <047.fcebd5e462086e021124f01f2c19fc8c@abbot.galois.com>
References: <047.fcebd5e462086e021124f01f2c19fc8c@abbot.galois.com>
Message-ID: <056.4d70d59838aa8846e1d6f37c7bc79a2a@abbot.galois.com>

#3637: ./configure doesn't understand Gentoo's build/host/target
----------------------------------+-----------------------------------------
  Reporter:  kolmodin             |          Owner:  igloo           
      Type:  merge                |         Status:  closed          
  Priority:  high                 |      Milestone:  6.12.2          
 Component:  Build System         |        Version:  6.12.1 RC1      
Resolution:  fixed                |       Keywords:  regression      
Difficulty:  Unknown              |             Os:  Unknown/Multiple
  Testcase:                       |   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------
Changes (by igloo):

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


Comment:

 Merged.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3637#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 08:32:46 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 08:04:54 2010
Subject: [GHC] #3815: System.Win32.Types.failWith segfaults on unknown
 error code
In-Reply-To: <049.587f27162a2b081c86f44d647b44a9da@abbot.galois.com>
References: <049.587f27162a2b081c86f44d647b44a9da@abbot.galois.com>
Message-ID: <058.a312e2b585a9d1f542ebffed3c9fb58f@abbot.galois.com>

#3815: System.Win32.Types.failWith segfaults on unknown error code
----------------------------------+-----------------------------------------
    Reporter:  dherington         |        Owner:  simonmar               
        Type:  bug                |       Status:  assigned               
    Priority:  high               |    Milestone:  6.12.2                 
   Component:  libraries (other)  |      Version:  6.10.1                 
    Keywords:  getErrorMessage    |   Difficulty:  Easy (less than 1 hour)
          Os:  Windows            |     Testcase:                         
Architecture:  Unknown/Multiple   |      Failure:  Runtime crash          
----------------------------------+-----------------------------------------
Changes (by simonmar):

  * owner:  => simonmar
  * status:  new => assigned


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3815#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 09:00:07 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 08:32:15 2010
Subject: [GHC] #3815: System.Win32.Types.failWith segfaults on unknown
 error code
In-Reply-To: <049.587f27162a2b081c86f44d647b44a9da@abbot.galois.com>
References: <049.587f27162a2b081c86f44d647b44a9da@abbot.galois.com>
Message-ID: <058.e9d3995e7599cdc08214f0df81c826fd@abbot.galois.com>

#3815: System.Win32.Types.failWith segfaults on unknown error code
----------------------------------+-----------------------------------------
    Reporter:  dherington         |        Owner:  igloo                  
        Type:  merge              |       Status:  new                    
    Priority:  high               |    Milestone:  6.12.2                 
   Component:  libraries (other)  |      Version:  6.10.1                 
    Keywords:  getErrorMessage    |   Difficulty:  Easy (less than 1 hour)
          Os:  Windows            |     Testcase:                         
Architecture:  Unknown/Multiple   |      Failure:  Runtime crash          
----------------------------------+-----------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * status:  assigned => new
  * type:  bug => merge


Comment:

 Fixed:

 {{{
 Fri Jan 22 12:28:22 GMT 2010  Simon Marlow <marlowsd@gmail.com>
   * failWith: allow GetErrorMessage to return NULL (#3815)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3815#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 09:41:48 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 09:13:56 2010
Subject: [GHC] #3812: segfault in maybePerformBlockedException
In-Reply-To: <045.59eb1e03b76bd0d318fceb3fb3f06570@abbot.galois.com>
References: <045.59eb1e03b76bd0d318fceb3fb3f06570@abbot.galois.com>
Message-ID: <054.4cb40ccfca5fe359df3b9aca5c59de18@abbot.galois.com>

#3812: segfault in maybePerformBlockedException
-------------------------------+--------------------------------------------
    Reporter:  duncan          |        Owner:                     
        Type:  bug             |       Status:  new                
    Priority:  normal          |    Milestone:  6.12.2             
   Component:  Runtime System  |      Version:  6.12.1             
    Keywords:                  |   Difficulty:                     
          Os:  Solaris         |     Testcase:                     
Architecture:  sparc           |      Failure:  Building GHC failed
-------------------------------+--------------------------------------------

Comment(by simonmar):

 I tried building the stable branch on sparky, and I get

 {{{
 "inplace/bin/ghc-stage1" -optc-Wall -optc-Wextra -optc-Wstrict-prototypes
 -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-
 Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-
 Wcast-align -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes
 -optc-Irts -optc-DCOMPILING_RTS -optc-DUSE_LIBFFI_FOR_ADJUSTORS -optc-fno-
 strict-aliasing -optc-fno-common -optc-Ilibffi/build/include -optc-fomit-
 frame-pointer -optc-DRtsWay=\"rts_v\" -optc-w   -H64m -O0 -fasm -Iincludes
 -Irts -DCOMPILING_RTS -package-name rts -static  -dcmm-lint
 -Ilibffi/build/include     -i -irts -irts/dist/build
 -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen
 -optc-O2   -c rts/StgCRun.c -o rts/dist/build/StgCRun.o
 /opt/gcc/bin/../../SUNW0scgfss/4.0.4/prod/bin/fbe:
 "/tmp/ghc18508_0/ghc18508_0.s", line 18: error: statement syntax
 /opt/gcc/bin/../../SUNW0scgfss/4.0.4/prod/bin/fbe:
 "/tmp/ghc18508_0/ghc18508_0.s", line 32: error: statement syntax
 }}}

 the .s file in question is

 {{{
         .section        ".text",#alloc,#execinstr,#progbits
         .file   "StgCRun.c"
         .hidden StgRun

         .section        ".text",#alloc,#execinstr,#progbits
         .align  4


         .global StgRun
 StgRun:
         sethi   %hi(0x2000),%g1
         xor     %g1,-96,%g1
         save    %sp,%g1,%sp
         jmpl    %i0,%o7
         nop
         sethi   %hi(0x1c00),%g1
         sethi   %hi(%l1),%i5
         xor     %g1,-1024,%g1
         add     %g1,%fp,%g1
         or      %g0,%g1,%o0

 .L900000111:
         .align  4

 .L900000112:
         .global StgReturn

 .L900000113:

 .L900000114:
         ld      [%i5+%lo(%l1)],%i0
         ret     ! Result =  %i0
         restore %g0,%g0,%g0
         .type   StgRun,2
         .size   StgRun,(.-StgRun)
         .ident  "cg: Sun Compiler Common 12 SunOS_sparc gccfss_lang
 2007/07/11"
         .ident  "GCC: (GNU) 4.0.4 (gccfss)"
         .ident  "iropt: Sun Compiler Common 12 SunOS_sparc gccfss_lang
 2007/07/11"
 }}}

 any ideas?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3812#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 10:22:33 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 09:54:41 2010
Subject: [GHC] #3780: unix-2.4.0.0 fails with base 4.1
In-Reply-To: <045.da767e73d04d85283e231ed41de5ef94@abbot.galois.com>
References: <045.da767e73d04d85283e231ed41de5ef94@abbot.galois.com>
Message-ID: <054.25275e5bf75758935d53b7a3e6635c30@abbot.galois.com>

#3780: unix-2.4.0.0 fails with base 4.1
---------------------------------+------------------------------------------
    Reporter:  duncan            |        Owner:  igloo                  
        Type:  merge             |       Status:  new                    
    Priority:  normal            |    Milestone:  6.12.2                 
   Component:  libraries/unix    |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:  Easy (less than 1 hour)
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Other                  
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  => igloo
  * type:  bug => merge


Comment:

 Fixed:

 {{{
 Wed Jan 13 11:38:03 GMT 2010  Simon Marlow <marlowsd@gmail.com>
   * fix base dependency: should be >= 4.2 (#3780), and bump verison to
 2.4.0.1
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3780#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 11:02:38 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 10:34:46 2010
Subject: [GHC] #3823: GHC 6.12 breaks combination of records and
 mutually recursive modules
In-Reply-To: <044.7cc1ab77124bd237b37d840aa7398830@abbot.galois.com>
References: <044.7cc1ab77124bd237b37d840aa7398830@abbot.galois.com>
Message-ID: <053.a43fb658282bbc5963015de25dc1c3f5@abbot.galois.com>

#3823: GHC 6.12 breaks combination of records and mutually recursive modules
----------------------------------------+-----------------------------------
  Reporter:  mboes                      |          Owner:  igloo           
      Type:  merge                      |         Status:  closed          
  Priority:  high                       |      Milestone:  6.12.2          
 Component:  Compiler                   |        Version:  6.12.1          
Resolution:  fixed                      |       Keywords:                  
Difficulty:                             |             Os:  Unknown/Multiple
  Testcase:  T3823                      |   Architecture:  Unknown/Multiple
   Failure:  GHC rejects valid program  |  
----------------------------------------+-----------------------------------
Changes (by igloo):

  * status:  new => closed
  * testcase:  => T3823
  * resolution:  => fixed


Comment:

 I've merged this, but the example fails to build (in both HEAD and 6.12)
 with this error:
 {{{
 T3823B.hs:8:6:
     Couldn't match expected type `A' against inferred type `Bool'
     In the first argument of `y', namely `a'
     In the expression: y a
     In the definition of `b': b = y a
 }}}
 which looks correct to me.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3823#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 11:17:53 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 10:50:08 2010
Subject: [GHC] #3835: unpleasant linker warning
Message-ID: <045.2d288deca53973a528ae4336b68ed9b8@abbot.galois.com>

#3835: unpleasant linker warning
------------------------+---------------------------------------------------
    Reporter:  maeder   |       Owner:              
        Type:  bug      |      Status:  new         
    Priority:  normal   |   Component:  Compiler    
     Version:  6.12.1   |    Keywords:              
          Os:  Solaris  |    Testcase:              
Architecture:  x86      |     Failure:  None/Unknown
------------------------+---------------------------------------------------
 When linking any binary (i.e. cabal) that uses the network package I get
 the following warning:

 {{{
 ld: warning: symbol `store' has differing types:
         (file /usr/lib/libnsl.so type=FUNC; file /home/pub-bkb/pc-
 solaris/ghc/ghc-6.12.1/lib/ghc-6.12.1/libHSrts_thr.a(Globals.thr_o)
 type=OBJT);
         /home/pub-bkb/pc-
 solaris/ghc/ghc-6.12.1/lib/ghc-6.12.1/libHSrts_thr.a(Globals.thr_o)
 definition taken
 ld: warning: symbol `store' has differing types:
         (file /usr/lib/libnsl.so type=FUNC; file /home/pub-bkb/pc-
 solaris/ghc/ghc-6.12.1/lib/ghc-6.12.1/libHSrts_thr.a(Globals.thr_o)
 type=OBJT);
 }}}

 I've got network-2.2.1.7 that as extra-libraries: nsl socket

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3835>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 11:22:38 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 10:54:49 2010
Subject: [GHC] #3835: unpleasant linker warning
In-Reply-To: <045.2d288deca53973a528ae4336b68ed9b8@abbot.galois.com>
References: <045.2d288deca53973a528ae4336b68ed9b8@abbot.galois.com>
Message-ID: <054.3b33662f6a3ff1967cf28bfc05227480@abbot.galois.com>

#3835: unpleasant linker warning
-------------------------------+--------------------------------------------
    Reporter:  maeder          |        Owner:  simonmar    
        Type:  bug             |       Status:  assigned    
    Priority:  high            |    Milestone:  6.12.2      
   Component:  Runtime System  |      Version:  6.12.1      
    Keywords:                  |   Difficulty:              
          Os:  Solaris         |     Testcase:              
Architecture:  x86             |      Failure:  None/Unknown
-------------------------------+--------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar
  * priority:  normal => high
  * status:  new => assigned
  * component:  Compiler => Runtime System
  * milestone:  => 6.12.2


Comment:

 `store` should be static; I'll fix.  Thanks for the report.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3835#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 11:57:01 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 11:29:10 2010
Subject: [GHC] #3835: unpleasant linker warning
In-Reply-To: <045.2d288deca53973a528ae4336b68ed9b8@abbot.galois.com>
References: <045.2d288deca53973a528ae4336b68ed9b8@abbot.galois.com>
Message-ID: <054.91550e640cee9f3e3326cfd6e92293ad@abbot.galois.com>

#3835: unpleasant linker warning
-------------------------------+--------------------------------------------
    Reporter:  maeder          |        Owner:  simonmar    
        Type:  bug             |       Status:  assigned    
    Priority:  high            |    Milestone:  6.12.2      
   Component:  Runtime System  |      Version:  6.12.1      
    Keywords:                  |   Difficulty:              
          Os:  Solaris         |     Testcase:              
Architecture:  x86             |      Failure:  None/Unknown
-------------------------------+--------------------------------------------

Comment(by maeder):

 Without "-threaded" this also applies to
 `lib/ghc-6.12.1/libHSrts.a(Globals.o) type=OBJT`.
 (I hope the corresponding code is shared)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3835#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 12:55:25 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 12:27:32 2010
Subject: [GHC] #3808: piping  binary files sometimes fail
In-Reply-To: <046.03975d9a46f4033a58b89642ef5736ae@abbot.galois.com>
References: <046.03975d9a46f4033a58b89642ef5736ae@abbot.galois.com>
Message-ID: <055.d3aeb6fda58065cadf5b63176833d38c@abbot.galois.com>

#3808: piping  binary files sometimes fail
-------------------------------+--------------------------------------------
    Reporter:  paolino         |        Owner:  simonmar     
        Type:  bug             |       Status:  assigned     
    Priority:  high            |    Milestone:  6.12.2       
   Component:  Compiler        |      Version:  6.12.1       
    Keywords:  pipe binary IO  |   Difficulty:               
          Os:  Linux           |     Testcase:               
Architecture:  x86_64 (amd64)  |      Failure:  Runtime crash
-------------------------------+--------------------------------------------
Description changed by igloo:

Old description:

> I'm having this random bug , sometimes code succeed, sometimes not.
> It must be noted that I had to choose 5000 to exploit the randomness of
> it
> With 10000 it always fail, with 100 it always succeed.
> Also substituting "take 5000 fibs" with [0..5000] it always succeed,
> probably because it's much faster.
>

> This is the console output, for 2 consecutive shots. Notice that faster
> machines, or different kernels could need a different 5000, or never show
> the bug.
>

> paolino@paolino-desktop:~$ ./prod | cat |./cons
> 5000
> paolino@paolino-desktop:~$ ./prod | cat |./cons
> cons: <stdin>: hLookAhead: invalid argument (Invalid or incomplete
> multibyte or wide character)

New description:

 I'm having this random bug , sometimes code succeed, sometimes not.
 It must be noted that I had to choose 5000 to exploit the randomness of it
 With 10000 it always fail, with 100 it always succeed.
 Also substituting "take 5000 fibs" with [0..5000] it always succeed,
 probably because it's much faster.


 This is the console output, for 2 consecutive shots. Notice that faster
 machines, or different kernels could need a different 5000, or never show
 the bug.

 {{{
 paolino@paolino-desktop:~$ ./prod | cat |./cons
 5000
 paolino@paolino-desktop:~$ ./prod | cat |./cons
 cons: <stdin>: hLookAhead: invalid argument (Invalid or incomplete
 multibyte or wide character)
 }}}

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3808#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 17:22:50 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 16:55:04 2010
Subject: [GHC] #3472: Porting through .hc files broken
In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@abbot.galois.com>
References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@abbot.galois.com>
Message-ID: <055.1a51ed1cd946538ed779b9275c9d1fc7@abbot.galois.com>

#3472: Porting through .hc files broken
---------------------------+------------------------------------------------
  Reporter:  pumpkin       |           Type:  bug             
    Status:  new           |       Priority:  normal          
 Milestone:  6.12 branch   |      Component:  Build System    
   Version:  6.12.1 RC1    |       Keywords:                  
Difficulty:  Unknown       |             Os:  Unknown/Multiple
  Testcase:                |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by galdor):

 * cc: khaelin@? (added)


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3472#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 18:08:16 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 17:40:22 2010
Subject: [GHC] #3836: ghc6 6.12.1 fails to build from source in S390
Message-ID: <044.fa2981fa8c9b1277f742d78343cf4e59@abbot.galois.com>

#3836: ghc6 6.12.1 fails to build from source in S390
-----------------------+----------------------------------------------------
    Reporter:  guest   |       Owner:                     
        Type:  bug     |      Status:  new                
    Priority:  normal  |   Component:  Documentation      
     Version:  6.12.1  |    Keywords:                     
          Os:  Linux   |    Testcase:                     
Architecture:  Other   |     Failure:  Building GHC failed
-----------------------+----------------------------------------------------
 This bug is reported in Debian BTS:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566331

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3836>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 18:46:39 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 18:18:46 2010
Subject: [GHC] #3799: undefined symbols and undefined references
 possibly related to template haskell
In-Reply-To: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
References: <049.4a0311c347285cc6754ed4f6a532bc0a@abbot.galois.com>
Message-ID: <058.bad0f4459455431f3ce11cfb022b102f@abbot.galois.com>

#3799: undefined symbols and undefined references possibly related to template
haskell
---------------------------------+------------------------------------------
  Reporter:  JeremyShaw          |          Owner:                                               
      Type:  bug                 |         Status:  closed                                       
  Priority:  normal              |      Milestone:  6.12.2                                       
 Component:  Compiler            |        Version:  6.13                                         
Resolution:  invalid             |       Keywords:  undefined symbols references template haskell
Difficulty:                      |             Os:  Unknown/Multiple                             
  Testcase:                      |   Architecture:  Unknown/Multiple                             
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------

Comment(by waern):

 Replying to [comment:13 Saizan]:
 > just for clarification: only recently haddock started building to object
 code and so triggering this bug, right?
 > Since the common case has always been calling cabal haddock just after
 cabal build and it used to work correctly.

 Yes, that's correct, Haddock started building to object code for TH
 modules relatively recently. It should have started with 2.4.2, released
 Mar 21 2009. Then we switched to the native code generator (instead of
 compiling via C) in 2.5.0. In the latest release we use the native code
 generator only on platforms where it's available.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 18:52:29 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 18:24:36 2010
Subject: [GHC] #3773: Haddoc documentation on wrong function argument
In-Reply-To: <044.635ed03af9d418169b269fce9db0718f@abbot.galois.com>
References: <044.635ed03af9d418169b269fce9db0718f@abbot.galois.com>
Message-ID: <053.e6270a207df34878ff6ec2ac132b96ec@abbot.galois.com>

#3773: Haddoc documentation on wrong function argument
----------------------------+-----------------------------------------------
  Reporter:  tibbe          |          Owner:  waern           
      Type:  bug            |         Status:  closed          
  Priority:  normal         |      Milestone:  6.12.2          
 Component:  Documentation  |        Version:  6.10.4          
Resolution:  fixed          |       Keywords:                  
Difficulty:                 |             Os:  Unknown/Multiple
  Testcase:                 |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown   |  
----------------------------+-----------------------------------------------
Changes (by waern):

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


Comment:

 Thanks Isaac!

 I've reviewed and applied the patch - it's working fine. I added a test
 case to the test suite.

 While I was there, I fixed another bug in the HTML-rendering of function
 argument docs. We were not parenthesizing arguments of function type. We
 should do that since we're actually rendering a Haskell expression.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3773#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 22 18:54:00 2010
From: trac at galois.com (GHC)
Date: Fri Jan 22 18:26:08 2010
Subject: [GHC] #3773: Haddoc documentation on wrong function argument
In-Reply-To: <044.635ed03af9d418169b269fce9db0718f@abbot.galois.com>
References: <044.635ed03af9d418169b269fce9db0718f@abbot.galois.com>
Message-ID: <053.1350fdc2e9670452c177d7fbd874c158@abbot.galois.com>

#3773: Haddoc documentation on wrong function argument
----------------------------+-----------------------------------------------
  Reporter:  tibbe          |          Owner:  waern           
      Type:  bug            |         Status:  reopened        
  Priority:  normal         |      Milestone:  6.12.2          
 Component:  Documentation  |        Version:  6.10.4          
Resolution:                 |       Keywords:                  
Difficulty:                 |             Os:  Unknown/Multiple
  Testcase:                 |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown   |  
----------------------------+-----------------------------------------------
Changes (by waern):

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


Comment:

 I guess we shouldn't close this one before the patch has applied to GHC's
 Haddock repo.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3773#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 23 13:55:47 2010
From: trac at galois.com (GHC)
Date: Sat Jan 23 13:27:52 2010
Subject: [GHC] #3837: hsc2hs and utf-8
Message-ID: <052.70cf87bf85ce9569a1df195436a13aa0@abbot.galois.com>

#3837: hsc2hs and utf-8
---------------------------------+------------------------------------------
    Reporter:  TaruKarttunen     |       Owner:              
        Type:  bug               |      Status:  new         
    Priority:  normal            |   Component:  Compiler    
     Version:  6.12.1            |    Keywords:              
          Os:  Unknown/Multiple  |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------
 hsc2hs is broken on a source file containing certain utf-8 characters in
 the comments.

 Attached is an example module.

 The probable culprit is:
     showCChar c    = ['\\',
                       intToDigit (ord c `quot` 64),
                       intToDigit (ord c `quot` 8 `mod` 8),
                       intToDigit (ord c          `mod` 8)]
 in hsc2hs code.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3837>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 23 14:03:55 2010
From: trac at galois.com (GHC)
Date: Sat Jan 23 13:35:58 2010
Subject: [GHC] #3837: hsc2hs and utf-8
In-Reply-To: <052.70cf87bf85ce9569a1df195436a13aa0@abbot.galois.com>
References: <052.70cf87bf85ce9569a1df195436a13aa0@abbot.galois.com>
Message-ID: <061.12a8fa5cb07f1a59cffa2afb306079ee@abbot.galois.com>

#3837: hsc2hs and utf-8
---------------------------------+------------------------------------------
    Reporter:  TaruKarttunen     |       Owner:              
        Type:  bug               |      Status:  new         
    Priority:  normal            |   Component:  Compiler    
     Version:  6.12.1            |    Keywords:              
          Os:  Unknown/Multiple  |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by TaruKarttunen):

 Not sure if the encoding got preserved.

 It is simply:

 oz:HsOpenSSL$ od -t x1 A.hsc
 0000000 2d 2d 20 e3 82 a8 0a
 0000007

 japanese:
 U+30A8  ?       e3 82 a8        KATAKANA LETTER E

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3837#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 23 14:28:06 2010
From: trac at galois.com (GHC)
Date: Sat Jan 23 14:00:08 2010
Subject: [GHC] #3837: hsc2hs and utf-8
In-Reply-To: <052.70cf87bf85ce9569a1df195436a13aa0@abbot.galois.com>
References: <052.70cf87bf85ce9569a1df195436a13aa0@abbot.galois.com>
Message-ID: <061.869d21faf290d2812266f79f0a1ce57b@abbot.galois.com>

#3837: hsc2hs and utf-8
---------------------------------+------------------------------------------
    Reporter:  TaruKarttunen     |       Owner:              
        Type:  bug               |      Status:  new         
    Priority:  normal            |   Component:  hsc2hs      
     Version:  6.12.1            |    Keywords:              
          Os:  Unknown/Multiple  |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by TaruKarttunen):

  * component:  Compiler => hsc2hs


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3837#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 25 06:55:54 2010
From: trac at galois.com (GHC)
Date: Mon Jan 25 06:28:02 2010
Subject: [GHC] #3835: unpleasant linker warning
In-Reply-To: <045.2d288deca53973a528ae4336b68ed9b8@abbot.galois.com>
References: <045.2d288deca53973a528ae4336b68ed9b8@abbot.galois.com>
Message-ID: <054.0ec02496461e25b4145d0babfd0e0f3d@abbot.galois.com>

#3835: unpleasant linker warning
-------------------------------+--------------------------------------------
    Reporter:  maeder          |        Owner:  igloo       
        Type:  merge           |       Status:  new         
    Priority:  high            |    Milestone:  6.12.2      
   Component:  Runtime System  |      Version:  6.12.1      
    Keywords:                  |   Difficulty:              
          Os:  Solaris         |     Testcase:              
Architecture:  x86             |      Failure:  None/Unknown
-------------------------------+--------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * status:  assigned => new
  * type:  bug => merge


Comment:

 Fixed (I believe, I don't have a Solaris box to reproduce):

 {{{
 Fri Jan 22 16:48:34 GMT 2010  Simon Marlow <marlowsd@gmail.com>
   * 'store' should be static (#3835)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3835#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 25 06:59:14 2010
From: trac at galois.com (GHC)
Date: Mon Jan 25 06:31:16 2010
Subject: [GHC] #3553: parallel gc suffers badly if one thread is
 descheduled
In-Reply-To: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@abbot.galois.com>
References: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@abbot.galois.com>
Message-ID: <056.4510d89923f4f3530e97b22991c30952@abbot.galois.com>

#3553: parallel gc suffers badly if one thread is descheduled
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  igloo       
        Type:  merge             |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  Runtime System    |      Version:  6.10.4      
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  => igloo
  * failure:  => None/Unknown
  * type:  bug => merge


Comment:

 This patch helps a lot:

 {{{
 Fri Jan 22 16:49:11 GMT 2010  Simon Marlow <marlowsd@gmail.com>
   * When acquiring a spinlock, yieldThread() every 1000 spins (#3553,
 #3758)

   This helps when the thread holding the lock has been descheduled,
   which is the main cause of the "last-core slowdown" problem.  With
   this patch, I get much better results with -N8 on an 8-core box,
   although some benchmarks are still worse than with 7 cores.

   I also added a yieldThread() into the any_work() loop of the parallel
   GC when it has no work to do. Oddly, this seems to improve performance
   on the parallel GC benchmarks even when all the cores are busy.
   Perhaps it is due to reducing contention on the memory bus.
 }}}

 See [http://ghcmutterings.wordpress.com/2010/01/25/yielding-more-
 improvements-in-parallel-performance/ this blog post] for more info.

 I'm going to close the bug, since I think this is the best we can do until
 we implement on-the-fly minor GCs.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3553#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 25 07:38:40 2010
From: trac at galois.com (GHC)
Date: Mon Jan 25 07:10:53 2010
Subject: [GHC] #3472: Porting through .hc files broken
In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@abbot.galois.com>
References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@abbot.galois.com>
Message-ID: <055.4f96dd3abb7030bdadcf28fb409244b6@abbot.galois.com>

#3472: Porting through .hc files broken
---------------------------+------------------------------------------------
  Reporter:  pumpkin       |           Type:  bug             
    Status:  new           |       Priority:  normal          
 Milestone:  6.12 branch   |      Component:  Build System    
   Version:  6.12.1 RC1    |       Keywords:                  
Difficulty:  Unknown       |             Os:  Unknown/Multiple
  Testcase:                |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by CBa):

 * cc: CBa (added)


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3472#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 25 08:04:53 2010
From: trac at galois.com (GHC)
Date: Mon Jan 25 07:36:53 2010
Subject: [GHC] #3838: Performance issues with blackholes
Message-ID: <047.ef7e7bc3345d4bdf14652daf490fba4d@abbot.galois.com>

#3838: Performance issues with blackholes
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  simonmar               
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  6.14 branch            
   Component:  Runtime System    |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------
 The attached program demonstrates an acute performance problem when many
 threads are blocking on blackholes.

 To run it:

 {{{
 $ cd event
 $ cabal configure && cabal build
 $ cd benchmarks
 $ make thread-delay
 $ ./thread-delay -n 20000
 }}}

 often the program completes in under a second, but sometimes it takes much
 longer (15s up to a minute).

 I diagnosed the problem: in this program, thousands of threads compete to
 update a single `IORef` using `atomicModifyIORef`.  If one of these
 threads is pre-empted while evaluating the thunk left in the `IORef` by
 `atomicModifyIORef`, then the thunk becomes a blackhole. From that point
 on, all the other threads become blocked on blackholes, as they each call
 `atomicModifyIORef` and evaluate the result.

 Eventually there are thousands of threads on the blackhole queue, and
 since this queue is traversed at least once and possibly several times
 during GC, performance drops severely.

 Some thoughts I've had follow.  There isn't an obvious good solution yet.

  * We can't attach blocked threads to the blackhole directly, due to the
 race conditions this would cause with parallel execution (we replaced the
 blackhole blocking queues with the global blackhole queue in 6.6 when
 implementing parallel execution).

  * maintaining a hash-table mapping blackholes to blocked threads would
 improve wakeup times, but wouldn't help here, because we'd then have a
 large hash table to update on each GC.  I have an unpushed patch to do
 just this sitting around; it didn't improve performance when I tried it,
 and is rather more complicated than the current design.

  * we could divide the blackhole queue into per-generation queues as we've
 done with several other data structures.  This would help GC to scale, but
 doesn't address the root problems.

  * If instead of blackholing the thunk we suspended it (ala `raiseAsync`),
 that would solve the problem.  It could be done in `threadPaused`, but how
 do we know when to do this?

  * Another solution along similar lines would be to just not blackhole the
 thunk at all: we let other threads evaluate it again.  This would make
 sense for thunks with a fixed known-small evaluation cost, such as
 selectors.  Unfortunately in this case the thunk in the `IORef` is not
 known to be small, although the two selector thunks also created by
 `atomicModifyIORef` do fall into this category.

  * If we knew which threads owned which blackholes, then we could arrange
 to schedule threads on which others were blocked more quickly.  This is
 like a priority-inversion problem: one thread is blocking all the others,
 we need to increase its priority.  Unfortunately we don't have a mapping
 from blackholes to threads available, and maintaining it would introduce
 an overhead.  In this case we have a cascade of threads blocked on each
 other, so choosing the right scheduling is particularly difficult.

  * Using STM would avoid the problem, as long as the program is careful to
 not store any thunks in a `TVar`.  However, STM is rather more expensive,
 and the reason for using `atomicModifyIORef` in the first place was speed.

  * Using `MVar` would ''not'' solve the problem, as `modifyMVar` can be
 pre-empted while holding the `MVar`, which would lead to a similar problem
 (in fact, it would be impossible for the RTS to do anything in this case,
 since we can't revert an `MVar` or know which thread is holding it).

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3838>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 25 08:09:10 2010
From: trac at galois.com (GHC)
Date: Mon Jan 25 07:41:09 2010
Subject: [GHC] #3838: Performance issues with blackholes
In-Reply-To: <047.ef7e7bc3345d4bdf14652daf490fba4d@abbot.galois.com>
References: <047.ef7e7bc3345d4bdf14652daf490fba4d@abbot.galois.com>
Message-ID: <056.ba1b5976a8220e79f0aefec90f340abe@abbot.galois.com>

#3838: Performance issues with blackholes
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  simonmar               
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  6.14 branch            
   Component:  Runtime System    |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------
Description changed by simonmar:

Old description:

> The attached program demonstrates an acute performance problem when many
> threads are blocking on blackholes.
>
> To run it:
>
> {{{
> $ cd event
> $ cabal configure && cabal build
> $ cd benchmarks
> $ make thread-delay
> $ ./thread-delay -n 20000
> }}}
>
> often the program completes in under a second, but sometimes it takes
> much longer (15s up to a minute).
>
> I diagnosed the problem: in this program, thousands of threads compete to
> update a single `IORef` using `atomicModifyIORef`.  If one of these
> threads is pre-empted while evaluating the thunk left in the `IORef` by
> `atomicModifyIORef`, then the thunk becomes a blackhole. From that point
> on, all the other threads become blocked on blackholes, as they each call
> `atomicModifyIORef` and evaluate the result.
>
> Eventually there are thousands of threads on the blackhole queue, and
> since this queue is traversed at least once and possibly several times
> during GC, performance drops severely.
>
> Some thoughts I've had follow.  There isn't an obvious good solution yet.
>
>  * We can't attach blocked threads to the blackhole directly, due to the
> race conditions this would cause with parallel execution (we replaced the
> blackhole blocking queues with the global blackhole queue in 6.6 when
> implementing parallel execution).
>
>  * maintaining a hash-table mapping blackholes to blocked threads would
> improve wakeup times, but wouldn't help here, because we'd then have a
> large hash table to update on each GC.  I have an unpushed patch to do
> just this sitting around; it didn't improve performance when I tried it,
> and is rather more complicated than the current design.
>
>  * we could divide the blackhole queue into per-generation queues as
> we've done with several other data structures.  This would help GC to
> scale, but doesn't address the root problems.
>
>  * If instead of blackholing the thunk we suspended it (ala
> `raiseAsync`), that would solve the problem.  It could be done in
> `threadPaused`, but how do we know when to do this?
>
>  * Another solution along similar lines would be to just not blackhole
> the thunk at all: we let other threads evaluate it again.  This would
> make sense for thunks with a fixed known-small evaluation cost, such as
> selectors.  Unfortunately in this case the thunk in the `IORef` is not
> known to be small, although the two selector thunks also created by
> `atomicModifyIORef` do fall into this category.
>
>  * If we knew which threads owned which blackholes, then we could arrange
> to schedule threads on which others were blocked more quickly.  This is
> like a priority-inversion problem: one thread is blocking all the others,
> we need to increase its priority.  Unfortunately we don't have a mapping
> from blackholes to threads available, and maintaining it would introduce
> an overhead.  In this case we have a cascade of threads blocked on each
> other, so choosing the right scheduling is particularly difficult.
>
>  * Using STM would avoid the problem, as long as the program is careful
> to not store any thunks in a `TVar`.  However, STM is rather more
> expensive, and the reason for using `atomicModifyIORef` in the first
> place was speed.
>
>  * Using `MVar` would ''not'' solve the problem, as `modifyMVar` can be
> pre-empted while holding the `MVar`, which would lead to a similar
> problem (in fact, it would be impossible for the RTS to do anything in
> this case, since we can't revert an `MVar` or know which thread is
> holding it).

New description:

 The attached program demonstrates an acute performance problem when many
 threads are blocking on blackholes.

 To run it:

 {{{
 $ cd event
 $ cabal configure && cabal build
 $ cd benchmarks
 $ make thread-delay
 $ ./thread-delay -n 20000
 }}}

 often the program completes in under a second, but sometimes it takes much
 longer (15s up to a minute).

 I diagnosed the problem: in this program, thousands of threads compete to
 update a single `IORef` using `atomicModifyIORef`.  If one of these
 threads is pre-empted while evaluating the thunk left in the `IORef` by
 `atomicModifyIORef`, then the thunk becomes a blackhole. From that point
 on, all the other threads become blocked on blackholes, as they each call
 `atomicModifyIORef` and evaluate the result.

 Eventually there are thousands of threads on the blackhole queue, and
 since this queue is traversed at least once and possibly several times
 during GC, performance drops severely.

 Some thoughts I've had follow.  There isn't an obvious good solution yet.

  * We can't attach blocked threads to the blackhole directly, due to the
 race conditions this would cause with parallel execution (we replaced the
 blackhole blocking queues with the global blackhole queue in 6.6 when
 implementing parallel execution).

  * maintaining a hash-table mapping blackholes to blocked threads would
 improve wakeup times, but wouldn't help here, because we'd then have a
 large hash table to update on each GC.  I have an unpushed patch to do
 just this sitting around (attached); it didn't improve performance when I
 tried it, and is rather more complicated than the current design.

  * we could divide the blackhole queue into per-generation queues as we've
 done with several other data structures.  This would help GC to scale, but
 doesn't address the root problems.

  * If instead of blackholing the thunk we suspended it (ala `raiseAsync`),
 that would solve the problem.  It could be done in `threadPaused`, but how
 do we know when to do this?

  * Another solution along similar lines would be to just not blackhole the
 thunk at all: we let other threads evaluate it again.  This would make
 sense for thunks with a fixed known-small evaluation cost, such as
 selectors.  Unfortunately in this case the thunk in the `IORef` is not
 known to be small, although the two selector thunks also created by
 `atomicModifyIORef` do fall into this category.

  * If we knew which threads owned which blackholes, then we could arrange
 to schedule threads on which others were blocked more quickly.  This is
 like a priority-inversion problem: one thread is blocking all the others,
 we need to increase its priority.  Unfortunately we don't have a mapping
 from blackholes to threads available, and maintaining it would introduce
 an overhead.  In this case we have a cascade of threads blocked on each
 other, so choosing the right scheduling is particularly difficult.

  * Using STM would avoid the problem, as long as the program is careful to
 not store any thunks in a `TVar`.  However, STM is rather more expensive,
 and the reason for using `atomicModifyIORef` in the first place was speed.

  * Using `MVar` would ''not'' solve the problem, as `modifyMVar` can be
 pre-empted while holding the `MVar`, which would lead to a similar problem
 (in fact, it would be impossible for the RTS to do anything in this case,
 since we can't revert an `MVar` or know which thread is holding it).

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3838#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 25 08:34:08 2010
From: trac at galois.com (GHC)
Date: Mon Jan 25 08:06:06 2010
Subject: [GHC] #3838: Performance issues with blackholes
In-Reply-To: <047.ef7e7bc3345d4bdf14652daf490fba4d@abbot.galois.com>
References: <047.ef7e7bc3345d4bdf14652daf490fba4d@abbot.galois.com>
Message-ID: <056.c68a292c45eb94e22adf2e36ab60dcd3@abbot.galois.com>

#3838: Performance issues with blackholes
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  simonmar               
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  6.14 branch            
   Component:  Runtime System    |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------
Description changed by simonmar:

Old description:

> The attached program demonstrates an acute performance problem when many
> threads are blocking on blackholes.
>
> To run it:
>
> {{{
> $ cd event
> $ cabal configure && cabal build
> $ cd benchmarks
> $ make thread-delay
> $ ./thread-delay -n 20000
> }}}
>
> often the program completes in under a second, but sometimes it takes
> much longer (15s up to a minute).
>
> I diagnosed the problem: in this program, thousands of threads compete to
> update a single `IORef` using `atomicModifyIORef`.  If one of these
> threads is pre-empted while evaluating the thunk left in the `IORef` by
> `atomicModifyIORef`, then the thunk becomes a blackhole. From that point
> on, all the other threads become blocked on blackholes, as they each call
> `atomicModifyIORef` and evaluate the result.
>
> Eventually there are thousands of threads on the blackhole queue, and
> since this queue is traversed at least once and possibly several times
> during GC, performance drops severely.
>
> Some thoughts I've had follow.  There isn't an obvious good solution yet.
>
>  * We can't attach blocked threads to the blackhole directly, due to the
> race conditions this would cause with parallel execution (we replaced the
> blackhole blocking queues with the global blackhole queue in 6.6 when
> implementing parallel execution).
>
>  * maintaining a hash-table mapping blackholes to blocked threads would
> improve wakeup times, but wouldn't help here, because we'd then have a
> large hash table to update on each GC.  I have an unpushed patch to do
> just this sitting around (attached); it didn't improve performance when I
> tried it, and is rather more complicated than the current design.
>
>  * we could divide the blackhole queue into per-generation queues as
> we've done with several other data structures.  This would help GC to
> scale, but doesn't address the root problems.
>
>  * If instead of blackholing the thunk we suspended it (ala
> `raiseAsync`), that would solve the problem.  It could be done in
> `threadPaused`, but how do we know when to do this?
>
>  * Another solution along similar lines would be to just not blackhole
> the thunk at all: we let other threads evaluate it again.  This would
> make sense for thunks with a fixed known-small evaluation cost, such as
> selectors.  Unfortunately in this case the thunk in the `IORef` is not
> known to be small, although the two selector thunks also created by
> `atomicModifyIORef` do fall into this category.
>
>  * If we knew which threads owned which blackholes, then we could arrange
> to schedule threads on which others were blocked more quickly.  This is
> like a priority-inversion problem: one thread is blocking all the others,
> we need to increase its priority.  Unfortunately we don't have a mapping
> from blackholes to threads available, and maintaining it would introduce
> an overhead.  In this case we have a cascade of threads blocked on each
> other, so choosing the right scheduling is particularly difficult.
>
>  * Using STM would avoid the problem, as long as the program is careful
> to not store any thunks in a `TVar`.  However, STM is rather more
> expensive, and the reason for using `atomicModifyIORef` in the first
> place was speed.
>
>  * Using `MVar` would ''not'' solve the problem, as `modifyMVar` can be
> pre-empted while holding the `MVar`, which would lead to a similar
> problem (in fact, it would be impossible for the RTS to do anything in
> this case, since we can't revert an `MVar` or know which thread is
> holding it).

New description:

 The attached program demonstrates an acute performance problem when many
 threads are blocking on blackholes.

 To run it:

 {{{
 $ cd event
 $ cabal configure && cabal build
 $ cd benchmarks
 $ make thread-delay
 $ ./thread-delay -n 20000
 }}}

 often the program completes in under a second, but sometimes it takes much
 longer (15s up to a minute).

 I diagnosed the problem: in this program, thousands of threads compete to
 update a single `IORef` using `atomicModifyIORef`.  If one of these
 threads is pre-empted while evaluating the thunk left in the `IORef` by
 `atomicModifyIORef`, then the thunk becomes a blackhole. From that point
 on, all the other threads become blocked on blackholes, as they each call
 `atomicModifyIORef` and evaluate the result.

 Eventually there are thousands of threads on the blackhole queue, and
 since this queue is traversed at least once and possibly several times
 during GC, performance drops severely.

 Some thoughts I've had follow.  There isn't an obvious good solution yet.

  * We can't attach blocked threads to the blackhole directly, due to the
 race conditions this would cause with parallel execution (we replaced the
 blackhole blocking queues with the global blackhole queue in 6.6 when
 implementing parallel execution).

  * maintaining a hash-table mapping blackholes to blocked threads would
 improve wakeup times, but wouldn't help here, because we'd then have a
 large hash table to update on each GC.  I have an unpushed patch to do
 just this sitting around (attached); it didn't improve performance when I
 tried it, and is rather more complicated than the current design.

  * we could divide the blackhole queue into per-generation queues as we've
 done with several other data structures.  This would help GC to scale, but
 doesn't address the root problems.

  * If instead of blackholing the thunk we suspended it (ala `raiseAsync`),
 that would solve the problem.  It could be done in `threadPaused`, but how
 do we know when to do this?

  * Another solution along similar lines would be to just not blackhole the
 thunk at all: we let other threads evaluate it again.  This would make
 sense for thunks with a fixed known-small evaluation cost, such as
 selectors.  Unfortunately in this case the thunk in the `IORef` is not
 known to be small, although the two selector thunks also created by
 `atomicModifyIORef` do fall into this category.  (Note however that
 blackholing is currently mandatory due to a problem that otherwise occurs
 in parallel GC: see `NOTE [upd-black-hole]` in
 [[GhcFile(rts/sm/Scav.c)]]).

  * If we knew which threads owned which blackholes, then we could arrange
 to schedule threads on which others were blocked more quickly.  This is
 like a priority-inversion problem: one thread is blocking all the others,
 we need to increase its priority.  Unfortunately we don't have a mapping
 from blackholes to threads available, and maintaining it would introduce
 an overhead.  In this case we have a cascade of threads blocked on each
 other, so choosing the right scheduling is particularly difficult.

  * Using STM would avoid the problem, as long as the program is careful to
 not store any thunks in a `TVar`.  However, STM is rather more expensive,
 and the reason for using `atomicModifyIORef` in the first place was speed.

  * Using `MVar` would ''not'' solve the problem, as `modifyMVar` can be
 pre-empted while holding the `MVar`, which would lead to a similar problem
 (in fact, it would be impossible for the RTS to do anything in this case,
 since we can't revert an `MVar` or know which thread is holding it).

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3838#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 25 08:47:35 2010
From: trac at galois.com (GHC)
Date: Mon Jan 25 08:19:32 2010
Subject: [GHC] #3758: Huge regression in concurrent app performance and
 reliability under threaded runtime
In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@abbot.galois.com>
References: <042.942d2a7fe8a29f75a39eae02838820a0@abbot.galois.com>
Message-ID: <051.90314951bd9498c55b7f068fafb26f12@abbot.galois.com>

#3758: Huge regression in concurrent app performance and reliability under
threaded runtime
-------------------------------+--------------------------------------------
    Reporter:  bos             |        Owner:  simonmar     
        Type:  bug             |       Status:  new          
    Priority:  high            |    Milestone:  6.12.2       
   Component:  Runtime System  |      Version:  6.12.1       
    Keywords:                  |   Difficulty:               
          Os:  Linux           |     Testcase:               
Architecture:  x86_64 (amd64)  |      Failure:  Runtime crash
-------------------------------+--------------------------------------------

Comment(by simonmar):

 After applying the patch from #3553, on a dual-core 1.2GHz Intel Core,
 Ubuntu Karmic:

  * HEAD, unthreaded: ~6300 req/sec
  * HEAD, -threaded -N1: ~6600 req/sec
  * HEAD, -threaded -N2: ~6600 req/sec
  * HEAD, -threaded -N2 -qg: ~6600 req/sec

 the numbers wobble around quite a bit, but as far as I can tell the
 problem is now gone.  I'll wait for confirmation from Bryan (maybe when we
 put out a 6.12.2 RC?) before closing the bug.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3758#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 25 12:31:26 2010
From: trac at galois.com (GHC)
Date: Mon Jan 25 12:03:28 2010
Subject: [GHC] #3553: parallel gc suffers badly if one thread is
 descheduled
In-Reply-To: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@abbot.galois.com>
References: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@abbot.galois.com>
Message-ID: <056.1055414f9ebf50e32a84434eb5f84d6f@abbot.galois.com>

#3553: parallel gc suffers badly if one thread is descheduled
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  igloo       
        Type:  merge             |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  Runtime System    |      Version:  6.10.4      
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by wuzzeb):

 I would be careful about adding sched_yield.  Ingo Molnar, the developer
 who wrote and maintains the linux scheduler, says he has never seen a
 valid use of sched_yield.  See
 http://kerneltrap.org/Linux/Using_sched_yield_Improperly for the
 discussion.  At least with the CFS scheduler in linux, using sched_yield
 might not always do what you expect.

 Also, from your blog post at least, it seems like futexes are perfect for
 what you need.  In the uncontended case, they are completely in userspace.
 They can be acquired on one thread and released on another thread.  Any
 reasons why futexes don't work?

 http://people.redhat.com/drepper/futex.pdf
 http://en.wikipedia.org/wiki/Futex

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3553#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 25 17:54:50 2010
From: trac at galois.com (GHC)
Date: Mon Jan 25 17:26:48 2010
Subject: [GHC] #3553: parallel gc suffers badly if one thread is
 descheduled
In-Reply-To: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@abbot.galois.com>
References: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@abbot.galois.com>
Message-ID: <056.7095bfd0e117aac87236ba3f5180792d@abbot.galois.com>

#3553: parallel gc suffers badly if one thread is descheduled
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  igloo       
        Type:  merge             |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  Runtime System    |      Version:  6.10.4      
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by simonmar):

 I tried using futexes today, and so far haven't managed to beat the
 performance of the `sched_yield` spinlocks, but I might not be using them
 right. I fully expect futexes to be better.  (also, futexes are not
 exactly a real API.  The syscall isn't even exposed by glibc, you have to
 define it manually, as I discovered with some help from folks on #ghc).

 I can entirely believe that `sched_yield` is never the absolute right
 thing, but it might be the best ''portable'' solution we have.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3553#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 00:16:15 2010
From: trac at galois.com (GHC)
Date: Mon Jan 25 23:48:12 2010
Subject: [GHC] #3838: Performance issues with blackholes
In-Reply-To: <047.ef7e7bc3345d4bdf14652daf490fba4d@abbot.galois.com>
References: <047.ef7e7bc3345d4bdf14652daf490fba4d@abbot.galois.com>
Message-ID: <056.b064cab817d7ee117f8e952a3a798263@abbot.galois.com>

#3838: Performance issues with blackholes
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  simonmar               
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  6.14 branch            
   Component:  Runtime System    |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------
Changes (by bos):

 * cc: bos@? (added)


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3838#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 04:36:24 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 04:08:23 2010
Subject: [GHC] #3839: ghc panic reading pragmas
Message-ID: <044.fe3ec9b01c0e5c8911e90e96a69aa083@abbot.galois.com>

#3839: ghc panic reading pragmas
---------------------------------+------------------------------------------
    Reporter:  guest             |       Owner:              
        Type:  bug               |      Status:  new         
    Priority:  normal            |   Component:  Compiler    
     Version:  6.10.4            |    Keywords:              
          Os:  Unknown/Multiple  |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------
 Ending a language pragma with a newline before the close-of-comment causes
 ghc to panic.  See attached file.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3839>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 04:37:48 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 04:09:43 2010
Subject: [GHC] #3839: ghc panic reading pragmas
In-Reply-To: <044.fe3ec9b01c0e5c8911e90e96a69aa083@abbot.galois.com>
References: <044.fe3ec9b01c0e5c8911e90e96a69aa083@abbot.galois.com>
Message-ID: <053.13d80a869584a445470d2cf389dfad25@abbot.galois.com>

#3839: ghc panic reading pragmas
---------------------------------+------------------------------------------
    Reporter:  guest             |       Owner:              
        Type:  bug               |      Status:  new         
    Priority:  normal            |   Component:  Compiler    
     Version:  6.10.4            |    Keywords:              
          Os:  Unknown/Multiple  |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by guest):

 GHC messages are:

 Prelude> :l blah.hs
 ghc: panic! (the 'impossible' happened)
   (GHC version 6.10.4 for x86_64-unknown-linux):
         getOptions'.parseLanguage(1) went past eof token

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3839#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 04:40:20 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 04:12:16 2010
Subject: [GHC] #3839: ghci panic reading pragmas (was: ghc panic reading
 pragmas)
In-Reply-To: <044.fe3ec9b01c0e5c8911e90e96a69aa083@abbot.galois.com>
References: <044.fe3ec9b01c0e5c8911e90e96a69aa083@abbot.galois.com>
Message-ID: <053.73d83240efb08b05b180b9a70650e2c3@abbot.galois.com>

#3839: ghci panic reading pragmas
--------------------------------------+-------------------------------------
Reporter:  guest                      |          Owner:                   
    Type:  bug                        |         Status:  closed           
Priority:  normal                     |      Component:  Compiler (Parser)
 Version:  6.10.4                     |     Resolution:  fixed            
Keywords:                             |             Os:  Unknown/Multiple 
Testcase:                             |   Architecture:  Unknown/Multiple 
 Failure:  GHC rejects valid program  |  
--------------------------------------+-------------------------------------
Changes (by guest):

  * status:  new => closed
  * failure:  None/Unknown => GHC rejects valid program
  * component:  Compiler => Compiler (Parser)
  * resolution:  => fixed


Comment:

 I'm now told this is fixed in 6.12 so I guess it's ok to close.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3839#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 06:45:59 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 06:17:55 2010
Subject: [GHC] #3553: parallel gc suffers badly if one thread is
 descheduled
In-Reply-To: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@abbot.galois.com>
References: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@abbot.galois.com>
Message-ID: <056.e031f2b1d9d312826cdf8ee3f76fb64a@abbot.galois.com>

#3553: parallel gc suffers badly if one thread is descheduled
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  igloo       
        Type:  merge             |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  Runtime System    |      Version:  6.10.4      
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by simonmar):

 Patch to use futexes attached.  This is significantly slower than the
 `sched_yield` version currently in use.  I don't know why - as far as I
 can tell I'm using futexes correctly.  The protocol I'm using is from
 Drepper's paper, and I tried it with and without some user-space spinning
 in the acquire case.

 nofib/parallel/ray on 8 cores, first with futexes and then with yield:

 {{{
 $ ./ray 1000 +RTS -N8 -s >/dev/null
   14,784,695,584 bytes allocated in the heap
      246,403,264 bytes copied during GC
          108,232 bytes maximum residency (169 sample(s))
          310,000 bytes maximum slop
                6 MB total memory in use (0 MB lost due to fragmentation)

   Generation 0:  4606 collections,  4605 parallel,  4.31s,  2.16s elapsed
   Generation 1:   169 collections,   169 parallel,  0.22s,  0.08s elapsed

   Parallel GC work balance: 1.56 (30214391 / 19430130, ideal 8)

   SPARKS: 1000000 (978174 converted, 21636 pruned)

   INIT  time    0.00s  (  0.00s elapsed)
   MUT   time    8.96s  (  1.86s elapsed)
   GC    time    4.53s  (  2.24s elapsed)
   EXIT  time    0.00s  (  0.00s elapsed)
   Total time   13.49s  (  4.11s elapsed)


 $ ./ray-yield 1000 +RTS -N8 -s >/dev/null
   14,834,802,304 bytes allocated in the heap
      237,105,080 bytes copied during GC
           97,736 bytes maximum residency (158 sample(s))
          299,160 bytes maximum slop
                6 MB total memory in use (0 MB lost due to fragmentation)

   Generation 0:  4515 collections,  4514 parallel,  7.73s,  1.65s elapsed
   Generation 1:   158 collections,   158 parallel,  0.39s,  0.06s elapsed

   Parallel GC work balance: 1.53 (29092959 / 18954020, ideal 8)

   SPARKS: 1000000 (980491 converted, 19356 pruned)

   INIT  time    0.00s  (  0.00s elapsed)
   MUT   time   10.74s  (  1.93s elapsed)
   GC    time    8.11s  (  1.71s elapsed)
   EXIT  time    0.00s  (  0.00s elapsed)
   Total time   18.86s  (  3.64s elapsed)
 }}}

 The extra CPU time in the yield version is due to the higher spin
 threshold, but I've tried different spin thresholds in the futex case and
 it didn't help.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3553#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 10:24:37 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 09:56:35 2010
Subject: [GHC] #3821: Trace.Hpc.Reflect.examineTix segfaults on 64bit
In-Reply-To: <053.fbf59e92eb99357652de0927fec4376a@abbot.galois.com>
References: <053.fbf59e92eb99357652de0927fec4376a@abbot.galois.com>
Message-ID: <062.88f828841cb5d511f437ee8f67e0b71c@abbot.galois.com>

#3821: Trace.Hpc.Reflect.examineTix segfaults on 64bit
---------------------------------+------------------------------------------
    Reporter:  TristanAllwood    |        Owner:  igloo       
        Type:  merge             |       Status:  new         
    Priority:  high              |    Milestone:  6.12.2      
   Component:  Code Coverage     |      Version:  6.12.1      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  x86_64 (amd64)    |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * status:  assigned => new
  * type:  bug => merge


Comment:

 Patch applied (packages/hpc):

 {{{
 Fri Jan 15 10:21:41 GMT 2010  tora@zonetora.co.uk
   * Use a fixed size value when reading from Memory for ModuleInfo's
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3821#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 11:02:54 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 10:34:49 2010
Subject: [GHC] #3790: control-C causes segfault,
 siginfo_t* can be NULL on Solaris
In-Reply-To: <045.d2557c16e92c7f9e5e2306103fb1f846@abbot.galois.com>
References: <045.d2557c16e92c7f9e5e2306103fb1f846@abbot.galois.com>
Message-ID: <054.af3e783d1363d1ac7de92326f7e58ca1@abbot.galois.com>

#3790: control-C causes segfault, siginfo_t* can be NULL on Solaris
-------------------------------+--------------------------------------------
    Reporter:  duncan          |        Owner:  simonmar     
        Type:  bug             |       Status:  assigned     
    Priority:  normal          |    Milestone:  6.12.2       
   Component:  Runtime System  |      Version:  6.12.1       
    Keywords:                  |   Difficulty:               
          Os:  Solaris         |     Testcase:               
Architecture:  sparc           |      Failure:  Runtime crash
-------------------------------+--------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar
  * status:  new => assigned


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3790#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 11:08:08 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 10:40:01 2010
Subject: [GHC] #3804: strange output of mkGHCConstants on SunOS 5.8/sparc
In-Reply-To: <042.aa6d3bd949f1a02a1e301e5062530c41@abbot.galois.com>
References: <042.aa6d3bd949f1a02a1e301e5062530c41@abbot.galois.com>
Message-ID: <051.54c36fd578a1316f89e07a79182a9352@abbot.galois.com>

#3804: strange output of mkGHCConstants on SunOS 5.8/sparc
-----------------------------+----------------------------------------------
    Reporter:  CBa           |        Owner:  simonmar           
        Type:  bug           |       Status:  assigned           
    Priority:  normal        |    Milestone:  6.12.2             
   Component:  Build System  |      Version:  6.12.1             
    Keywords:                |   Difficulty:                     
          Os:  Solaris       |     Testcase:                     
Architecture:  sparc         |      Failure:  Building GHC failed
-----------------------------+----------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar
  * status:  new => assigned


Comment:

 I'll fix this.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3804#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 11:15:21 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 10:47:17 2010
Subject: [GHC] #2929: INFINITY used in .hc files without -std=c99
In-Reply-To: <045.9c2069ffa5b68c9fb1e9f0987d2d791e@abbot.galois.com>
References: <045.9c2069ffa5b68c9fb1e9f0987d2d791e@abbot.galois.com>
Message-ID: <054.64b51e61c1913d6eaca30c3535383d12@abbot.galois.com>

#2929: INFINITY used in .hc files without -std=c99
-------------------------------+--------------------------------------------
    Reporter:  duncan          |        Owner:  simonmar    
        Type:  bug             |       Status:  assigned    
    Priority:  normal          |    Milestone:  6.12.2      
   Component:  Runtime System  |      Version:  6.8.3       
    Keywords:                  |   Difficulty:  Unknown     
          Os:  Solaris         |     Testcase:  1861        
Architecture:  sparc           |      Failure:  None/Unknown
-------------------------------+--------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar
  * status:  new => assigned


Comment:

 I'm on this one.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2929#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 11:20:40 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 10:52:35 2010
Subject: [GHC] #3793: System.Time.toClockTime does not support all valid
 timezone offsets.
In-Reply-To: <045.573376566b5efc770151c67d8f432e86@abbot.galois.com>
References: <045.573376566b5efc770151c67d8f432e86@abbot.galois.com>
Message-ID: <054.16decd7f530cbe408c8e038545afc760@abbot.galois.com>

#3793: System.Time.toClockTime does not support all valid timezone offsets.
----------------------------------------+-----------------------------------
    Reporter:  daniel                   |        Owner:  igloo                      
        Type:  merge                    |       Status:  new                        
    Priority:  high                     |    Milestone:  6.12.2                     
   Component:  libraries/old-time       |      Version:                             
    Keywords:  tz timezone toClockTime  |   Difficulty:  Easy (less than 1 hour)    
          Os:  Unknown/Multiple         |     Testcase:                             
Architecture:  Unknown/Multiple         |      Failure:  Incorrect result at runtime
----------------------------------------+-----------------------------------
Changes (by simonmar):

  * owner:  => igloo
  * type:  bug => merge


Comment:

 Applied (packages/old-time):

 {{{
 Mon Dec 28 22:07:03 GMT 2009  Daniel McAllansmith <dm.maillists@gmail.com>
   * Support timezone offsets up to +1400.
   Many places have timezone offsets greater than the previously allowed
 maximum
   of +1200, especially when in DST.
   Parts of Kiribati are +1400.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3793#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 11:22:35 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 10:54:31 2010
Subject: [GHC] #3758: Huge regression in concurrent app performance and
 reliability under threaded runtime
In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@abbot.galois.com>
References: <042.942d2a7fe8a29f75a39eae02838820a0@abbot.galois.com>
Message-ID: <051.cfc5c1a063ecdb517b14aeaf118f3e12@abbot.galois.com>

#3758: Huge regression in concurrent app performance and reliability under
threaded runtime
-------------------------------+--------------------------------------------
    Reporter:  bos             |        Owner:  simonmar     
        Type:  bug             |       Status:  new          
    Priority:  high            |    Milestone:  6.12.2       
   Component:  Runtime System  |      Version:  6.12.1       
    Keywords:                  |   Difficulty:               
          Os:  Linux           |     Testcase:               
Architecture:  x86_64 (amd64)  |      Failure:  Runtime crash
-------------------------------+--------------------------------------------

Comment(by simonmar):

 I just fixed a deadlock.  I'm not sure if it's your deadlock, but fingers
 crossed.

 {{{
 Tue Jan 26 07:00:37 PST 2010  Simon Marlow <marlowsd@gmail.com>
   * Fix a deadlock, and possibly other problems
   After a bound thread had completed, its TSO remains in the heap until
   it has been GC'd, although the associated Task is returned to the
   caller where it is freed and possibly re-used.

   The bug was that GC was following the pointer to the Task and updating
   the TSO field, meanwhile the Task had already been recycled (it was
   being used by exitScheduler()). Confusion ensued, leading to a very
   occasional deadlock at shutdown, but in principle it could result in
   other crashes too.

   The fix is to remove the link between the TSO and the Task when the
   TSO has completed and the call to schedule() has returned; see
   comments in Schedule.c.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3758#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 11:47:06 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 11:19:02 2010
Subject: [GHC] #3758: Huge regression in concurrent app performance and
 reliability under threaded runtime
In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@abbot.galois.com>
References: <042.942d2a7fe8a29f75a39eae02838820a0@abbot.galois.com>
Message-ID: <051.da314c1bd5ede1c0fa625a856e56196a@abbot.galois.com>

#3758: Huge regression in concurrent app performance and reliability under
threaded runtime
-------------------------------+--------------------------------------------
    Reporter:  bos             |        Owner:  simonmar     
        Type:  bug             |       Status:  new          
    Priority:  high            |    Milestone:  6.12.2       
   Component:  Runtime System  |      Version:  6.12.1       
    Keywords:                  |   Difficulty:               
          Os:  Linux           |     Testcase:               
Architecture:  x86_64 (amd64)  |      Failure:  Runtime crash
-------------------------------+--------------------------------------------

Comment(by bos):

 Thanks for working on this, Simon. It'll be a few days before I have a
 chance to look at the results, at the very least.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3758#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 11:55:57 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 11:27:59 2010
Subject: [GHC] #3840: ghc-6.12.1 takes longer to compile code and produces
 bigger binaries compared to ghc-6.10.4
Message-ID: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>

#3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries
compared to ghc-6.10.4
-----------------------+----------------------------------------------------
    Reporter:  maeder  |       Owner:              
        Type:  bug     |      Status:  new         
    Priority:  normal  |   Component:  Compiler    
     Version:  6.12.1  |    Keywords:              
          Os:  Linux   |    Testcase:              
Architecture:  x86     |     Failure:  None/Unknown
-----------------------+----------------------------------------------------
 Compiling 348 files from our hets project (using "cabal build")

 using ghc-6.12.1 (from
 http://www.haskell.org/ghc/dist/6.12.1/ghc-6.12.1-i386-unknown-
 linux-n.tar.bz2)
 takes 291.55s and produces a binary with 21540628 Bytes (after strip)

 using ghc-6.10.4 (from
 http://www.haskell.org/ghc/dist/6.10.4/ghc-6.10.4-i386-unknown-
 linux-n.tar.bz2)
 takes 216.28s and produces a binary with 14548284 Bytes (after strip)

 Furthermore the stripped ghc (and haddock) binaries from the distributions
 differ already:

 ghc-6.12.1 17MB
 ghc-6.10.4 14MB

 (The ghc-6.12.1 distribution misses the install-strip target)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3840>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 11:58:08 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 11:30:15 2010
Subject: [GHC] #3812: segfault in maybePerformBlockedException
In-Reply-To: <045.59eb1e03b76bd0d318fceb3fb3f06570@abbot.galois.com>
References: <045.59eb1e03b76bd0d318fceb3fb3f06570@abbot.galois.com>
Message-ID: <054.b075a7cfcb1672038a95f253a33b006d@abbot.galois.com>

#3812: segfault in maybePerformBlockedException
----------------------------------+-----------------------------------------
  Reporter:  duncan               |          Owner:         
      Type:  bug                  |         Status:  closed 
  Priority:  normal               |      Milestone:  6.12.2 
 Component:  Runtime System       |        Version:  6.12.1 
Resolution:  worksforme           |       Keywords:         
Difficulty:                       |             Os:  Solaris
  Testcase:                       |   Architecture:  sparc  
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------
Changes (by simonmar):

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


Comment:

 After fixing my build, I'm not seeing this bug.  Let's re-open the ticket
 if it comes back.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3812#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 17:36:10 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 17:08:04 2010
Subject: [GHC] #3353: Add CLDouble support
In-Reply-To: <044.199bb36c514cf1226e0efa905a8fa4ca@abbot.galois.com>
References: <044.199bb36c514cf1226e0efa905a8fa4ca@abbot.galois.com>
Message-ID: <053.c3a397c2ab0d90d3edf80c4f2b1c3036@abbot.galois.com>

#3353: Add CLDouble support
---------------------------------+------------------------------------------
    Reporter:  igloo             |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  _|_         
   Component:  Compiler          |      Version:  6.12.1      
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by guest):

 error while compiling C2HS with GHC 6.12.1


 {{{
 [24 of 26] Compiling C2HS.C.Info      ( src/C2HS/C/Info.hs,
 dist/build/c2hs/c2hs-tmp/C2HS/C/Info.o )

 src/C2HS/C/Info.hs:117:53:
     Not in scope: type constructor or class `CLDouble'

 src/C2HS/C/Info.hs:142:70:
     Not in scope: type constructor or class `CLDouble'
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3353#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 17:56:50 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 17:28:48 2010
Subject: [GHC] #3841: build for libffi assumes tar supports -z
Message-ID: <045.69f9c4089a918348ebb9aaa08d9cec23@abbot.galois.com>

#3841: build for libffi assumes tar supports -z
---------------------------------+------------------------------------------
    Reporter:  duncan            |       Owner:                     
        Type:  bug               |      Status:  new                
    Priority:  normal            |   Component:  Build System       
     Version:  6.12.1            |    Keywords:                     
          Os:  Solaris           |    Testcase:                     
Architecture:  Unknown/Multiple  |     Failure:  Building GHC failed
---------------------------------+------------------------------------------
 {{{
 cd libffi && /usr/bin/tar -zxf ../ghc-tarballs/libffi/libffi*.tar.gz
 tar: z: unknown function modifier
 Usage: tar {c|r|t|u|x}[BDeEFhilmnopPqTvw@[0-7]][bfk][X...] [blocksize]
 [tarfile] [size] [exclude-file...] {file | -I include-file | -C directory
 file}...
 gmake[1]: *** [libffi/stamp.ffi.configure] Error 1
 }}}

 The libffi/ghc.mk uses
 {{{
 cd libffi && $(TAR) -zxf ../ghc-tarballs/libffi/libffi*.tar.gz
 }}}
 A quick grep indicates this is the only instance that assumes the -z flag.
 Other instances in the ghc build system that use tar do the compression
 separately, eg in ghc.mk:
 {{{
 "$(TAR)" chf - $(SRC_DIST_NAME) 2>$src_log | bzip2
 >$(TOP)/$(SRC_DIST_TARBALL)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3841>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 18:00:29 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 17:32:23 2010
Subject: [GHC] #3842: build system does not pass selected gcc when
 configuring unix package
Message-ID: <045.96ccbbc84d3351743755cc616547d345@abbot.galois.com>

#3842: build system does not pass selected gcc when configuring unix package
---------------------------------+------------------------------------------
    Reporter:  duncan            |       Owner:                     
        Type:  bug               |      Status:  new                
    Priority:  normal            |   Component:  Build System       
     Version:  6.12.1            |    Keywords:                     
          Os:  Unknown/Multiple  |    Testcase:                     
Architecture:  Unknown/Multiple  |     Failure:  Building GHC failed
---------------------------------+------------------------------------------
 The build system's top level `./configure` has a flag `--with-gcc=`. All
 the library packages except the unix package use the same gcc. The unix
 package either does not get passed the selected location of gcc, or it
 ignores it. The ./configure for the unix package picks up the gcc from the
 $PATH.

 This can be reproduced by putting a dummy gcc in your $PATH that is just a
 symlink to `/bin/false` and using a top level `./configure --with-gcc=`

 When it gets to building the unix package it picks up the gcc from the
 $PATH:
 {{{
 Configuring unix-2.4.0.0...
 configure: WARNING: unrecognized options: --with-compiler, --with-cc
 checking for gcc... gcc
 checking whether the C compiler works... no
 }}}

 This bug is platform independent but it's most relevant on Solaris where
 the default gcc is not usable by ghc.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3842>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 18:50:08 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 18:22:01 2010
Subject: [GHC] #3841: build for libffi assumes tar supports -z
In-Reply-To: <045.69f9c4089a918348ebb9aaa08d9cec23@abbot.galois.com>
References: <045.69f9c4089a918348ebb9aaa08d9cec23@abbot.galois.com>
Message-ID: <054.42c4bfdd8e661217e24e22da767ce2b8@abbot.galois.com>

#3841: build for libffi assumes tar supports -z
---------------------------------+------------------------------------------
    Reporter:  duncan            |       Owner:                     
        Type:  bug               |      Status:  new                
    Priority:  normal            |   Component:  Build System       
     Version:  6.12.1            |    Keywords:                     
          Os:  Solaris           |    Testcase:                     
Architecture:  Unknown/Multiple  |     Failure:  Building GHC failed
---------------------------------+------------------------------------------

Comment(by duncan):

 Spoke too soon, another instance in `libraries/integer-gmp/gmp/ghc.mk`
 {{{
 cd libraries/integer-gmp/gmp && $(TAR) -jxf ../../../$(GMP_TARBALL)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3841#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 19:09:06 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 18:41:00 2010
Subject: [GHC] #3808: piping  binary files sometimes fail
In-Reply-To: <046.03975d9a46f4033a58b89642ef5736ae@abbot.galois.com>
References: <046.03975d9a46f4033a58b89642ef5736ae@abbot.galois.com>
Message-ID: <055.24280cafa25aa5d1666dd5f8af4debef@abbot.galois.com>

#3808: piping  binary files sometimes fail
-------------------------------+--------------------------------------------
    Reporter:  paolino         |        Owner:  simonmar     
        Type:  bug             |       Status:  assigned     
    Priority:  high            |    Milestone:  6.12.2       
   Component:  Compiler        |      Version:  6.12.1       
    Keywords:  pipe binary IO  |   Difficulty:               
          Os:  Linux           |     Testcase:               
Architecture:  x86_64 (amd64)  |      Failure:  Runtime crash
-------------------------------+--------------------------------------------

Comment(by igloo):

 This is now in HEAD and 6.12:
 {{{
 Tue Jan 12 23:03:17 GMT 2010  Simon Marlow <marlowsd@gmail.com>
   * hIsEOF: don't do any decoding (#3808)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3808#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 19:10:25 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 18:42:20 2010
Subject: [GHC] #3780: unix-2.4.0.0 fails with base 4.1
In-Reply-To: <045.da767e73d04d85283e231ed41de5ef94@abbot.galois.com>
References: <045.da767e73d04d85283e231ed41de5ef94@abbot.galois.com>
Message-ID: <054.adf6905643c109618041a78a1cbd885c@abbot.galois.com>

#3780: unix-2.4.0.0 fails with base 4.1
--------------------------------------+-------------------------------------
  Reporter:  duncan                   |          Owner:  igloo           
      Type:  merge                    |         Status:  closed          
  Priority:  normal                   |      Milestone:  6.12.2          
 Component:  libraries/unix           |        Version:  6.12.1          
Resolution:  fixed                    |       Keywords:                  
Difficulty:  Easy (less than 1 hour)  |             Os:  Unknown/Multiple
  Testcase:                           |   Architecture:  Unknown/Multiple
   Failure:  Other                    |  
--------------------------------------+-------------------------------------
Changes (by igloo):

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


Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3780#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 19:11:46 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 18:43:39 2010
Subject: [GHC] #3815: System.Win32.Types.failWith segfaults on unknown
 error code
In-Reply-To: <049.587f27162a2b081c86f44d647b44a9da@abbot.galois.com>
References: <049.587f27162a2b081c86f44d647b44a9da@abbot.galois.com>
Message-ID: <058.7a3ddee519e9eee0a4ba324d0b2ae428@abbot.galois.com>

#3815: System.Win32.Types.failWith segfaults on unknown error code
--------------------------------------+-------------------------------------
  Reporter:  dherington               |          Owner:  igloo           
      Type:  merge                    |         Status:  closed          
  Priority:  high                     |      Milestone:  6.12.2          
 Component:  libraries (other)        |        Version:  6.10.1          
Resolution:  fixed                    |       Keywords:  getErrorMessage 
Difficulty:  Easy (less than 1 hour)  |             Os:  Windows         
  Testcase:                           |   Architecture:  Unknown/Multiple
   Failure:  Runtime crash            |  
--------------------------------------+-------------------------------------
Changes (by igloo):

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


Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3815#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 20:33:35 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 20:05:37 2010
Subject: [GHC] #3835: unpleasant linker warning
In-Reply-To: <045.2d288deca53973a528ae4336b68ed9b8@abbot.galois.com>
References: <045.2d288deca53973a528ae4336b68ed9b8@abbot.galois.com>
Message-ID: <054.48f4e1d24e61634015655afc47bab539@abbot.galois.com>

#3835: unpleasant linker warning
-----------------------------+----------------------------------------------
  Reporter:  maeder          |          Owner:  igloo  
      Type:  merge           |         Status:  closed 
  Priority:  high            |      Milestone:  6.12.2 
 Component:  Runtime System  |        Version:  6.12.1 
Resolution:  fixed           |       Keywords:         
Difficulty:                  |             Os:  Solaris
  Testcase:                  |   Architecture:  x86    
   Failure:  None/Unknown    |  
-----------------------------+----------------------------------------------
Changes (by igloo):

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


Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3835#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 26 20:35:06 2010
From: trac at galois.com (GHC)
Date: Tue Jan 26 20:07:00 2010
Subject: [GHC] #3553: parallel gc suffers badly if one thread is
 descheduled
In-Reply-To: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@abbot.galois.com>
References: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@abbot.galois.com>
Message-ID: <056.bf7d8cfcace864577de51541ba0bbb6e@abbot.galois.com>

#3553: parallel gc suffers badly if one thread is descheduled
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  simonmar    
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  Runtime System    |      Version:  6.10.4      
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * owner:  igloo => simonmar
  * type:  merge => bug


Comment:

 Patch merged. Simon, I'm bouncing it back to you in case you want it left
 open for the futex investigation.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3553#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 05:39:41 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 05:11:35 2010
Subject: [GHC] #3843: Merge plugins into HEAD
Message-ID: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>

#3843: Merge plugins into HEAD
---------------------------------+------------------------------------------
    Reporter:  dreixel           |       Owner:  simonpj     
        Type:  merge             |      Status:  new         
    Priority:  normal            |   Component:  Compiler    
     Version:  6.13              |    Keywords:              
          Os:  Unknown/Multiple  |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------
 This ticket serves to track the progress of the integration of core
 plugins in GHC (see http://www.haskell.org/pipermail/glasgow-haskell-
 users/2010-January/018294.html). If you are interested in having Max
 Bolingbroke's work merged into the mainline, please add yourself to the CC
 list of this ticket, preferably also commenting saying why you want
 plugins.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3843>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 05:42:36 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 05:14:30 2010
Subject: [GHC] #3843: Merge plugins into HEAD
In-Reply-To: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>
References: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>
Message-ID: <055.fc8606ae152f321ddc68f136a0d842e7@abbot.galois.com>

#3843: Merge plugins into HEAD
---------------------------------+------------------------------------------
    Reporter:  dreixel           |       Owner:  simonpj     
        Type:  merge             |      Status:  new         
    Priority:  normal            |   Component:  Compiler    
     Version:  6.13              |    Keywords:              
          Os:  Unknown/Multiple  |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by dreixel):

 I would want core plugins to experiment with certain optimizations for
 generic programs, mostly related to inlining. Since this is rather
 experimental, plugins would allow easy modification of the core-to-core
 pass for testing (rather than having to recompile the compiler with an
 extra hard-coded core-to-core pass).

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3843#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 06:11:46 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 05:43:40 2010
Subject: [GHC] #3553: parallel gc suffers badly if one thread is
 descheduled
In-Reply-To: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@abbot.galois.com>
References: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@abbot.galois.com>
Message-ID: <056.58a7f91ea04b8293edf2da3b02f56b83@abbot.galois.com>

#3553: parallel gc suffers badly if one thread is descheduled
-----------------------------+----------------------------------------------
  Reporter:  simonmar        |          Owner:  simonmar        
      Type:  bug             |         Status:  closed          
  Priority:  normal          |      Milestone:  6.12.2          
 Component:  Runtime System  |        Version:  6.10.4          
Resolution:  fixed           |       Keywords:                  
Difficulty:  Unknown         |             Os:  Unknown/Multiple
  Testcase:                  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown    |  
-----------------------------+----------------------------------------------
Changes (by simonmar):

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


Comment:

 I'm not going to investigate this any more.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3553#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 06:13:36 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 05:45:28 2010
Subject: [GHC] #2966: build system does not respect --with-gcc=
In-Reply-To: <045.38910ced362f70db06ad52953362394b@abbot.galois.com>
References: <045.38910ced362f70db06ad52953362394b@abbot.galois.com>
Message-ID: <054.828c731614bd44017e83d73644580274@abbot.galois.com>

#2966: build system does not respect --with-gcc=
----------------------------------+-----------------------------------------
  Reporter:  duncan               |          Owner:  igloo           
      Type:  bug                  |         Status:  reopened        
  Priority:  normal               |      Milestone:  6.12.2          
 Component:  Build System         |        Version:  6.12.1          
Resolution:                       |       Keywords:                  
Difficulty:  Unknown              |             Os:  Unknown/Multiple
  Testcase:                       |   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------
Changes (by simonmar):

  * milestone:  6.12 branch => 6.12.2


Comment:

 See also dup #3842

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2966#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 06:14:11 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 05:46:04 2010
Subject: [GHC] #3842: build system does not pass selected gcc when
 configuring unix package
In-Reply-To: <045.96ccbbc84d3351743755cc616547d345@abbot.galois.com>
References: <045.96ccbbc84d3351743755cc616547d345@abbot.galois.com>
Message-ID: <054.549ac4bf3fa6545c0616246461c7c293@abbot.galois.com>

#3842: build system does not pass selected gcc when configuring unix package
----------------------------------+-----------------------------------------
  Reporter:  duncan               |          Owner:                  
      Type:  bug                  |         Status:  closed          
  Priority:  normal               |      Milestone:                  
 Component:  Build System         |        Version:  6.12.1          
Resolution:  duplicate            |       Keywords:                  
Difficulty:                       |             Os:  Unknown/Multiple
  Testcase:                       |   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------
Changes (by simonmar):

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


Comment:

 Duplicate of #2966

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3842#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 07:12:04 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 06:43:56 2010
Subject: [GHC] #3790: control-C causes segfault,
 siginfo_t* can be NULL on Solaris
In-Reply-To: <045.d2557c16e92c7f9e5e2306103fb1f846@abbot.galois.com>
References: <045.d2557c16e92c7f9e5e2306103fb1f846@abbot.galois.com>
Message-ID: <054.c61f3d798dcc74a2c84759f8a1fa7228@abbot.galois.com>

#3790: control-C causes segfault, siginfo_t* can be NULL on Solaris
-------------------------------+--------------------------------------------
    Reporter:  duncan          |        Owner:  igloo        
        Type:  merge           |       Status:  new          
    Priority:  normal          |    Milestone:  6.12.2       
   Component:  Runtime System  |      Version:  6.12.1       
    Keywords:                  |   Difficulty:               
          Os:  Solaris         |     Testcase:               
Architecture:  sparc           |      Failure:  Runtime crash
-------------------------------+--------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * status:  assigned => new
  * type:  bug => merge


Comment:

 Fixed:

 {{{
 Tue Jan 26 07:54:49 PST 2010  Simon Marlow <marlowsd@gmail.com>
   * Fix signal segfaults on Solaris (#3790)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3790#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 07:12:54 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 06:44:45 2010
Subject: [GHC] #3804: strange output of mkGHCConstants on SunOS 5.8/sparc
In-Reply-To: <042.aa6d3bd949f1a02a1e301e5062530c41@abbot.galois.com>
References: <042.aa6d3bd949f1a02a1e301e5062530c41@abbot.galois.com>
Message-ID: <051.a0624b6d103458e4d60b6bfefd8513e0@abbot.galois.com>

#3804: strange output of mkGHCConstants on SunOS 5.8/sparc
-----------------------------+----------------------------------------------
    Reporter:  CBa           |        Owner:  igloo              
        Type:  merge         |       Status:  new                
    Priority:  normal        |    Milestone:  6.12.2             
   Component:  Build System  |      Version:  6.12.1             
    Keywords:                |   Difficulty:                     
          Os:  Solaris       |     Testcase:                     
Architecture:  sparc         |      Failure:  Building GHC failed
-----------------------------+----------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * status:  assigned => new
  * type:  bug => merge


Comment:

 Fixed:

 {{{
 Tue Jan 26 08:33:22 PST 2010  Simon Marlow <marlowsd@gmail.com>
   * avoid using non-standard %zd format specifier (#3804)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3804#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 07:13:34 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 06:45:26 2010
Subject: [GHC] #3803: addCoverageTicksTobind should not panic when file
 location is Nothing
In-Reply-To: <046.170aea52f7935907ca6deb8869a6f4be@abbot.galois.com>
References: <046.170aea52f7935907ca6deb8869a6f4be@abbot.galois.com>
Message-ID: <055.b422430482f77e623be2ca5eccc78f96@abbot.galois.com>

#3803: addCoverageTicksTobind should not panic when file location is Nothing
---------------------------------+------------------------------------------
    Reporter:  clemens           |        Owner:  igloo       
        Type:  bug               |       Status:  new         
    Priority:  high              |    Milestone:  6.12.2      
   Component:  Compiler          |      Version:  6.12.1      
    Keywords:  hpc               |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  => igloo


Comment:

 Fixed:

 {{{
 Wed Jan 27 03:32:05 PST 2010  Simon Marlow <marlowsd@gmail.com>
   * addCoverageTicksToBinds: tolerate a non-existent .hs file (#3803)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3803#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 07:14:10 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 06:46:02 2010
Subject: [GHC] #3803: addCoverageTicksTobind should not panic when file
 location is Nothing
In-Reply-To: <046.170aea52f7935907ca6deb8869a6f4be@abbot.galois.com>
References: <046.170aea52f7935907ca6deb8869a6f4be@abbot.galois.com>
Message-ID: <055.409cf37e31cf19b2077fdc6dca1aa063@abbot.galois.com>

#3803: addCoverageTicksTobind should not panic when file location is Nothing
---------------------------------+------------------------------------------
    Reporter:  clemens           |        Owner:  igloo       
        Type:  merge             |       Status:  new         
    Priority:  high              |    Milestone:  6.12.2      
   Component:  Compiler          |      Version:  6.12.1      
    Keywords:  hpc               |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by simonmar):

  * type:  bug => merge


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3803#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 07:33:42 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 07:05:36 2010
Subject: [GHC] #3745: Non-deterministic behavior with FFI
In-Reply-To: <048.13932c70c5ac7d2182ef99747868ffe2@abbot.galois.com>
References: <048.13932c70c5ac7d2182ef99747868ffe2@abbot.galois.com>
Message-ID: <057.98a0090b4856582da8e5179be29e7a78@abbot.galois.com>

#3745: Non-deterministic behavior with FFI
------------------------------------------+---------------------------------
  Reporter:  gchrupala                    |          Owner:                  
      Type:  bug                          |         Status:  closed          
  Priority:  high                         |      Milestone:  6.12.2          
 Component:  Compiler (FFI)               |        Version:  6.10.4          
Resolution:  worksforme                   |       Keywords:                  
Difficulty:                               |             Os:  Unknown/Multiple
  Testcase:                               |   Architecture:  x86_64 (amd64)  
   Failure:  Incorrect result at runtime  |  
------------------------------------------+---------------------------------
Changes (by simonmar):

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


Comment:

 I can't reproduce it on x86-64/Linux either.  I suspect a hardware problem
 on your machine - to eliminate this possibility, try to reproduce it on
 another machine.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3745#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 07:53:04 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 07:24:56 2010
Subject: [GHC] #2966: build system does not respect --with-gcc=
In-Reply-To: <045.38910ced362f70db06ad52953362394b@abbot.galois.com>
References: <045.38910ced362f70db06ad52953362394b@abbot.galois.com>
Message-ID: <054.0ea34e16e3e9c95afa2330dcbf196588@abbot.galois.com>

#2966: build system does not respect --with-gcc=
----------------------------------+-----------------------------------------
  Reporter:  duncan               |          Owner:  igloo           
      Type:  merge                |         Status:  new             
  Priority:  normal               |      Milestone:  6.12.2          
 Component:  Build System         |        Version:  6.12.1          
Resolution:                       |       Keywords:                  
Difficulty:  Unknown              |             Os:  Unknown/Multiple
  Testcase:                       |   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------
Changes (by simonmar):

  * status:  reopened => new
  * type:  bug => merge


Comment:

 Fixed (libraries/unix):

 {{{
 Wed Jan 27 11:43:29 GMT 2010  Simon Marlow <marlowsd@gmail.com>
   * accept --with-cc to set the path to gcc (#2966)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2966#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 08:03:22 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 07:35:22 2010
Subject: [GHC] #3840: ghc-6.12.1 takes longer to compile code and
 produces bigger binaries compared to ghc-6.10.4
In-Reply-To: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
References: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
Message-ID: <054.addd16e14f43c8ad1b81d9f9b9f2679e@abbot.galois.com>

#3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries
compared to ghc-6.10.4
-----------------------+----------------------------------------------------
    Reporter:  maeder  |       Owner:              
        Type:  bug     |      Status:  new         
    Priority:  normal  |   Component:  Compiler    
     Version:  6.12.1  |    Keywords:              
          Os:  Linux   |    Testcase:              
Architecture:  x86     |     Failure:  None/Unknown
-----------------------+----------------------------------------------------

Comment(by maeder):

 looking at the object files this looks similar to #955

 ghc-6.10.4
 {{{
 684K dist/build/hets/hets-tmp/HasCASL/ATC_HasCASL.o
 624K dist/build/hets/hets-tmp/ATC/Sml_cats.o
 552K dist/build/hets/hets-tmp/CASL/ATC_CASL.o
 540K dist/build/hets/hets-tmp/SoftFOL/Sign.o
 520K dist/build/hets/hets-tmp/OMDoc/OMDocInterface.o
 504K dist/build/hets/hets-tmp/Static/DevGraph.o
 }}}

 ghc-6.12.1
 {{{
  2,8M dist/build/hets/hets-tmp/HasCASL/ATC_HasCASL.o
  2,2M dist/build/hets/hets-tmp/CASL/ATC_CASL.o
  1,6M dist/build/hets/hets-tmp/OWL/ReadWrite.o
  1,5M dist/build/hets/hets-tmp/CspCASL/ATC_CspCASL.o
  1,2M dist/build/hets/hets-tmp/OMDoc/ATC_OMDoc.o
  1,1M dist/build/hets/hets-tmp/Isabelle/ATC_Isabelle.o
  1,1M dist/build/hets/hets-tmp/SoftFOL/ATC_SoftFOL.o
 }}}

 That is, instances are expanded too much.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3840#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 08:06:32 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 07:38:26 2010
Subject: [GHC] #3756: Missing -lz option in testsuite
In-Reply-To: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com>
References: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com>
Message-ID: <065.cd80c88fafe4f2bb8d577ed6088d7158@abbot.galois.com>

#3756: Missing -lz option in testsuite
--------------------------------+-------------------------------------------
  Reporter:  daniel.is.fischer  |           Type:  bug         
    Status:  new                |       Priority:  normal      
 Milestone:  6.12.2             |      Component:  Build System
   Version:  6.12.1             |       Keywords:              
Difficulty:                     |             Os:  Linux       
  Testcase:                     |   Architecture:  x86         
   Failure:  Other              |  
--------------------------------+-------------------------------------------

Comment(by simonmar):

 I'm guessing that you have a static `libbfd.a` on your system, but no
 shared version, correct?  It looks like `libbfd` depends on `libz`.  We
 link against `libbfd` in the DEBUG version of the RTS, to get access to
 the addresses of symbols, and we test that `-lbfd` works in the configure
 script, but I imagine that because you have a static `libbfd` that the
 test doesn't link in the bit that needs `libz` and thus succeeds.

 The easiest workaround is for you to install a shared `libbfd`.  We could
 fix the configure test, but I'm not sure how to do it properly.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3756#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 08:32:45 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 08:04:50 2010
Subject: [GHC] #3748: Bug in rts/Win32/Ticker.c can cause process hang
 on exit in Win32
In-Reply-To: <042.ebc1303ba4ba1bb01245ae57d2b8c614@abbot.galois.com>
References: <042.ebc1303ba4ba1bb01245ae57d2b8c614@abbot.galois.com>
Message-ID: <051.82f6299eb2efe2b7a6cde6ba6010f906@abbot.galois.com>

#3748: Bug in rts/Win32/Ticker.c can cause process hang on exit in Win32
---------------------------------+------------------------------------------
    Reporter:  sgf               |        Owner:  simonmar     
        Type:  bug               |       Status:  assigned     
    Priority:  normal            |    Milestone:  6.12.2       
   Component:  Runtime System    |      Version:  6.10.4       
    Keywords:                    |   Difficulty:               
          Os:  Windows           |     Testcase:               
Architecture:  Unknown/Multiple  |      Failure:  Runtime crash
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar
  * status:  new => assigned


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3748#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 08:35:11 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 08:07:05 2010
Subject: [GHC] #3840: ghc-6.12.1 takes longer to compile code and
 produces bigger binaries compared to ghc-6.10.4
In-Reply-To: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
References: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
Message-ID: <054.bf74d5d2531e9756883d387d3e4c8335@abbot.galois.com>

#3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries
compared to ghc-6.10.4
-----------------------+----------------------------------------------------
    Reporter:  maeder  |       Owner:              
        Type:  bug     |      Status:  new         
    Priority:  normal  |   Component:  Compiler    
     Version:  6.12.1  |    Keywords:              
          Os:  Linux   |    Testcase:              
Architecture:  x86     |     Failure:  None/Unknown
-----------------------+----------------------------------------------------

Comment(by maeder):

 Changing the generated instances to one-liners plus auxiliary function (as
 helped for #955) does not help much now:

 ghc-6.12.1 with one-liner instances
 {{{
  2,2M dist/build/hets/hets-tmp/CASL/ATC_CASL.o
  2,1M dist/build/hets/hets-tmp/HasCASL/ATC_HasCASL.o
  1,6M dist/build/hets/hets-tmp/OWL/ReadWrite.o
  1,2M dist/build/hets/hets-tmp/CspCASL/ATC_CspCASL.o
  1,1M dist/build/hets/hets-tmp/OMDoc/ATC_OMDoc.o
  1,1M dist/build/hets/hets-tmp/SoftFOL/ATC_SoftFOL.o
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3840#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 08:52:07 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 08:23:58 2010
Subject: [GHC] #3756: Missing -lz option in testsuite
In-Reply-To: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com>
References: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com>
Message-ID: <065.0fe4344835258215f0d516c83fb40a79@abbot.galois.com>

#3756: Missing -lz option in testsuite
--------------------------------+-------------------------------------------
  Reporter:  daniel.is.fischer  |           Type:  bug         
    Status:  new                |       Priority:  normal      
 Milestone:  6.12.2             |      Component:  Build System
   Version:  6.12.1             |       Keywords:              
Difficulty:                     |             Os:  Linux       
  Testcase:                     |   Architecture:  x86         
   Failure:  Other              |  
--------------------------------+-------------------------------------------
Changes (by daniel.is.fischer):

 * cc: daniel.is.fischer@? (added)


Comment:

 I have a shared libbfd:
 {{{
 $ locate libbfd
 /usr/lib/libbfd-2.19.so
 /usr/lib/libbfd.a
 }}}
 The version number on the shared can't screw things up, can it?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3756#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 09:18:15 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 08:50:06 2010
Subject: [GHC] #3656: ghci leaves /tmp/ghc* directory if killed by signal
In-Reply-To: <042.d95f8802b8c0b09855d12a49e63b7a91@abbot.galois.com>
References: <042.d95f8802b8c0b09855d12a49e63b7a91@abbot.galois.com>
Message-ID: <051.a241536c4fb5dc413e40e536b9f7b607@abbot.galois.com>

#3656: ghci leaves /tmp/ghc* directory if killed by signal
---------------------------------+------------------------------------------
    Reporter:  vvv               |        Owner:  simonmar    
        Type:  bug               |       Status:  assigned    
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  GHCi              |      Version:  6.10.4      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar
  * status:  new => assigned


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3656#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 09:21:19 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 08:53:11 2010
Subject: [GHC] #3795: Haddock executable not versioned
In-Reply-To: <046.6038e00fcfe0d713d23c23af281a15cb@abbot.galois.com>
References: <046.6038e00fcfe0d713d23c23af281a15cb@abbot.galois.com>
Message-ID: <055.c08517eb7afdbc09cc4fc5aa94a46975@abbot.galois.com>

#3795: Haddock executable not versioned
---------------------------------+------------------------------------------
    Reporter:  lpsmith           |        Owner:        
        Type:  bug               |       Status:  new   
    Priority:  normal            |    Milestone:  6.12.2
   Component:  Documentation     |      Version:  6.12.1
    Keywords:                    |   Difficulty:        
          Os:  Unknown/Multiple  |     Testcase:        
Architecture:  Unknown/Multiple  |      Failure:  Other 
---------------------------------+------------------------------------------
Changes (by daniel.is.fischer):

 * cc: daniel.is.fischer@? (added)


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3795#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 09:47:33 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 09:19:39 2010
Subject: [GHC] #3843: Merge plugins into HEAD
In-Reply-To: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>
References: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>
Message-ID: <055.4abbc31b3a8c3b352c91aa9848d7db09@abbot.galois.com>

#3843: Merge plugins into HEAD
---------------------------------+------------------------------------------
    Reporter:  dreixel           |        Owner:  simonpj     
        Type:  task              |       Status:  new         
    Priority:  normal            |    Milestone:              
   Component:  Compiler          |      Version:  6.13        
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * type:  merge => task


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3843#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 09:52:40 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 09:24:31 2010
Subject: [GHC] #2929: INFINITY used in .hc files without -std=c99
In-Reply-To: <045.9c2069ffa5b68c9fb1e9f0987d2d791e@abbot.galois.com>
References: <045.9c2069ffa5b68c9fb1e9f0987d2d791e@abbot.galois.com>
Message-ID: <054.2b5373068fb3fbeeb63c263165ffd707@abbot.galois.com>

#2929: INFINITY used in .hc files without -std=c99
-------------------------------+--------------------------------------------
    Reporter:  duncan          |        Owner:  igloo       
        Type:  merge           |       Status:  new         
    Priority:  normal          |    Milestone:  6.12.2      
   Component:  Runtime System  |      Version:  6.8.3       
    Keywords:                  |   Difficulty:  Unknown     
          Os:  Solaris         |     Testcase:  1861        
Architecture:  sparc           |      Failure:  None/Unknown
-------------------------------+--------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * status:  assigned => new
  * type:  bug => merge


Comment:

 Fixed:

 {{{
 Wed Jan 27 13:36:32 GMT 2010  Simon Marlow <marlowsd@gmail.com>
   * define INFINITY and NAN if they don't exist (#2929)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2929#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 09:53:17 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 09:25:09 2010
Subject: [GHC] #3656: ghci leaves /tmp/ghc* directory if killed by signal
In-Reply-To: <042.d95f8802b8c0b09855d12a49e63b7a91@abbot.galois.com>
References: <042.d95f8802b8c0b09855d12a49e63b7a91@abbot.galois.com>
Message-ID: <051.a6cc308e89e38a9a6367e393b55b38ca@abbot.galois.com>

#3656: ghci leaves /tmp/ghc* directory if killed by signal
---------------------------------+------------------------------------------
    Reporter:  vvv               |        Owner:  igloo       
        Type:  merge             |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  GHCi              |      Version:  6.10.4      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * status:  assigned => new
  * type:  bug => merge


Comment:

 Fixed:

 {{{
 Wed Jan 27 14:04:38 GMT 2010  Simon Marlow <marlowsd@gmail.com>
   * catch SIGHUP and SIGTERM and raise an exception (#3656)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3656#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 10:12:21 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 09:44:22 2010
Subject: [GHC] #3843: Merge plugins into HEAD
In-Reply-To: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>
References: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>
Message-ID: <055.14be0a9f80f55b779e7a7bdaa4d6e821@abbot.galois.com>

#3843: Merge plugins into HEAD
---------------------------------+------------------------------------------
    Reporter:  dreixel           |        Owner:  simonpj     
        Type:  task              |       Status:  new         
    Priority:  normal            |    Milestone:              
   Component:  Compiler          |      Version:  6.13        
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by pumpkin):

 * cc: pumpkingod@? (added)


Comment:

 I'd like to use plugins to help show the programmer what rewrite rules are
 firing and where. The current most verbose simplifier output doesn't
 provide enough information to allow an external program to figure out what
 was rewritten and where (it just says that a rule fired and gives the new
 version of the code). This would help to find performance bugs in fusion-
 heavy code for example.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3843#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 10:42:22 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 10:14:21 2010
Subject: [GHC] #3840: ghc-6.12.1 takes longer to compile code and
 produces bigger binaries compared to ghc-6.10.4
In-Reply-To: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
References: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
Message-ID: <054.352f4e2ced27c42d398fb7bb414970d8@abbot.galois.com>

#3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries
compared to ghc-6.10.4
-------------------------+--------------------------------------------------
    Reporter:  maeder    |        Owner:              
        Type:  bug       |       Status:  new         
    Priority:  normal    |    Milestone:              
   Component:  Compiler  |      Version:  6.12.1      
    Keywords:            |   Difficulty:              
          Os:  Linux     |     Testcase:              
Architecture:  x86       |      Failure:  None/Unknown
-------------------------+--------------------------------------------------

Comment(by simonpj):

 Sorry about this.  It's jolly annoying.  I don't know what's going on
 here, and unfortunately it's difficult to reproduce because only you have
 the code, and it doubtless depends on a zillion other libraries.

 Is it possible to try with HEAD?  It has the new inlining story, which has
 changed (yet again) the way in which instances are treated.  If it's
 different it'd be helpful to know.

 Maybe try with `-dshow-passes` (both with 6.10 and 6.12) which should show
 in which pass the blow up happens.

 You take one of the offending modules, and cut it down so that there is
 (say) just one instance declaration that demonstrates the blow up?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3840#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 10:50:43 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 10:22:37 2010
Subject: [GHC] #3843: Merge plugins into HEAD
In-Reply-To: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>
References: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>
Message-ID: <055.b5ca77fcb8a007ca67e78848e5b0a628@abbot.galois.com>

#3843: Merge plugins into HEAD
---------------------------------+------------------------------------------
    Reporter:  dreixel           |        Owner:  simonpj     
        Type:  task              |       Status:  new         
    Priority:  normal            |    Milestone:              
   Component:  Compiler          |      Version:  6.13        
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by simonpj):

 A core-to-core plugin pass does just what it sounds like: transforms the
 program to a new program.  I don't know a good way for a plugin to monitor
 what ''another'' core-to-core pass is doing; in this case the rewrite
 rules, which are fired by the Simplifier.  It's not clear to me how to do
 that.  What would it mean to "figure out what was rewritten and where",
 when the whole program is being radically transformed?

 It's a good goal, but I don't currently know how to achieve it.

 There is a (slightly moribund) core-to-core pass, enabled by `-frule-
 check`, that looks for places where a rule nearly (but not quite) applies,
 and reports those.  So it might be a start for what you want. The code is
 in `Rules.ruleCheckProgram`.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3843#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 10:50:59 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 10:22:51 2010
Subject: [GHC] #3727: several Haiku platform defs
In-Reply-To: <043.0c45c6547023fdad014a8678dc73ea96@abbot.galois.com>
References: <043.0c45c6547023fdad014a8678dc73ea96@abbot.galois.com>
Message-ID: <052.d23fbe86106be3fd2918e65517a795f8@abbot.galois.com>

#3727: several Haiku platform defs
----------------------------------+-----------------------------------------
  Reporter:  donn                 |          Owner:  simonmar  
      Type:  bug                  |         Status:  closed    
  Priority:  normal               |      Milestone:  6.14.1    
 Component:  Compiler             |        Version:  6.12.1 RC1
Resolution:  fixed                |       Keywords:            
Difficulty:                       |             Os:  Other     
  Testcase:                       |   Architecture:  x86       
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------

Comment(by igloo):

 Also merged to 6.12 branch.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3727#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 11:40:08 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 11:12:01 2010
Subject: [GHC] #3840: ghc-6.12.1 takes longer to compile code and
 produces bigger binaries compared to ghc-6.10.4
In-Reply-To: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
References: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
Message-ID: <054.8167e9e9bca0d4eb6765992d76372c1b@abbot.galois.com>

#3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries
compared to ghc-6.10.4
-------------------------+--------------------------------------------------
    Reporter:  maeder    |        Owner:              
        Type:  bug       |       Status:  new         
    Priority:  normal    |    Milestone:              
   Component:  Compiler  |      Version:  6.12.1      
    Keywords:            |   Difficulty:              
          Os:  Linux     |     Testcase:              
Architecture:  x86       |      Failure:  None/Unknown
-------------------------+--------------------------------------------------

Comment(by maeder):

 Maybe you (or someone else) could check if (or why) the ghc binary itself
 is much bigger when compiled with ghc-6.12.1 versus ghc-6.10.4. Or why the
 new binary distribution is so much bigger?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3840#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 11:51:58 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 11:23:50 2010
Subject: [GHC] #3756: Missing -lz option in testsuite
In-Reply-To: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com>
References: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com>
Message-ID: <065.b9d531532d6e3bd3c6d63e1b85df282a@abbot.galois.com>

#3756: Missing -lz option in testsuite
--------------------------------+-------------------------------------------
  Reporter:  daniel.is.fischer  |           Type:  bug         
    Status:  new                |       Priority:  normal      
 Milestone:  6.12.2             |      Component:  Build System
   Version:  6.12.1             |       Keywords:              
Difficulty:                     |             Os:  Linux       
  Testcase:                     |   Architecture:  x86         
   Failure:  Other              |  
--------------------------------+-------------------------------------------

Comment(by simonmar):

 Perhaps in that case your libbfd requires libz, but it is not linked
 against it?  Can you look for those `inflate` symbols?  My `libbfd.a` here
 doesn't refer to them.

 What Linux distro is this, BTW?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3756#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 11:57:12 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 11:29:10 2010
Subject: [GHC] #3840: ghc-6.12.1 takes longer to compile code and
 produces bigger binaries compared to ghc-6.10.4
In-Reply-To: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
References: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
Message-ID: <054.6ed5122ef98c982be078763096b2ff25@abbot.galois.com>

#3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries
compared to ghc-6.10.4
-------------------------+--------------------------------------------------
    Reporter:  maeder    |        Owner:              
        Type:  bug       |       Status:  new         
    Priority:  normal    |    Milestone:              
   Component:  Compiler  |      Version:  6.12.1      
    Keywords:            |   Difficulty:              
          Os:  Linux     |     Testcase:              
Architecture:  x86       |      Failure:  None/Unknown
-------------------------+--------------------------------------------------

Comment(by simonmar):

 Replying to [comment:4 maeder]:
 > Maybe you (or someone else) could check if (or why) the ghc binary
 itself is much bigger when compiled with ghc-6.12.1 versus ghc-6.10.4. Or
 why the new binary distribution is so much bigger?

 One reason the GHC binary is bigger is that it now has all the native code
 generators compiled in, whereas in 6.10 it only had one.  Doubtless the
 compiler has just got bigger between 6.10 and 6.12 too.

 The distribution is bigger because it now contains shared libraries.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3840#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 12:04:19 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 11:36:14 2010
Subject: [GHC] #3840: ghc-6.12.1 takes longer to compile code and
 produces bigger binaries compared to ghc-6.10.4
In-Reply-To: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
References: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
Message-ID: <054.0b5b9c42d8cfb67469bbbbf7c90b301c@abbot.galois.com>

#3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries
compared to ghc-6.10.4
-------------------------+--------------------------------------------------
    Reporter:  maeder    |        Owner:              
        Type:  bug       |       Status:  new         
    Priority:  normal    |    Milestone:              
   Component:  Compiler  |      Version:  6.12.1      
    Keywords:            |   Difficulty:              
          Os:  Linux     |     Testcase:              
Architecture:  x86       |      Failure:  None/Unknown
-------------------------+--------------------------------------------------

Comment(by simonmar):

 Replying to [comment:5 simonmar]:

 > One reason the GHC binary is bigger is that it now has all the native
 code generators compiled in, whereas in 6.10 it only had one.  Doubtless
 the compiler has just got bigger between 6.10 and 6.12 too.
 >
 > The distribution is bigger because it now contains shared libraries.

 I should add that we did measure binary sizes for nofib before releasing
 6.12.1, and we found that while the size of binaries typically increased
 by around 10\%, the size of individually compiled modules wasn't much
 different, which means that the increase is generally due to more code,
 rather than unnecessary inlining for example.

 Another thing that we added is the new IO library: Unicode support makes
 the base package bigger.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3840#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 12:24:29 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 11:56:21 2010
Subject: [GHC] #3756: Missing -lz option in testsuite
In-Reply-To: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com>
References: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com>
Message-ID: <065.6c2c635757cfa746235290bd479c1d64@abbot.galois.com>

#3756: Missing -lz option in testsuite
--------------------------------+-------------------------------------------
  Reporter:  daniel.is.fischer  |           Type:  bug         
    Status:  new                |       Priority:  normal      
 Milestone:  6.12.2             |      Component:  Build System
   Version:  6.12.1             |       Keywords:              
Difficulty:                     |             Os:  Linux       
  Testcase:                     |   Architecture:  x86         
   Failure:  Other              |  
--------------------------------+-------------------------------------------

Comment(by daniel.is.fischer):

 What nm spits out:
 {{{
 $ nm -D /usr/lib/libbfd-2.19.so | grep inflate
          U inflate
          U inflateEnd
          U inflateInit_
          U inflateReset
 $ nm /usr/lib/libbfd.a | grep inflate
          U inflate
          U inflateEnd
          U inflateInit_
          U inflateReset
 }}}
 Does that help you? I guess it means you're right, it needs libz.

 The distro is openSUSE 11.1.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3756#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 13:36:11 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 13:08:14 2010
Subject: [GHC] #3840: ghc-6.12.1 takes longer to compile code and
 produces bigger binaries compared to ghc-6.10.4
In-Reply-To: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
References: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
Message-ID: <054.d69de16b8e275bde90db5de48bb421f5@abbot.galois.com>

#3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries
compared to ghc-6.10.4
-------------------------+--------------------------------------------------
    Reporter:  maeder    |        Owner:              
        Type:  bug       |       Status:  new         
    Priority:  normal    |    Milestone:              
   Component:  Compiler  |      Version:  6.12.1      
    Keywords:            |   Difficulty:              
          Os:  Linux     |     Testcase:              
Architecture:  x86       |      Failure:  None/Unknown
-------------------------+--------------------------------------------------

Comment(by maeder):

 Interestingly, if I compile the two big files directly, they stay small.
 It seems that compiling unrelated modules before increases .o files.

 {{{
 > ghc --make -DTIME_WITH_TYPEABLE HasCASL/ATC_HasCASL.hs
 [ 1 of 34] Compiling Common.InjMap    ( Common/InjMap.hs, Common/InjMap.o
 )
 ...
 [34 of 34] Compiling HasCASL.ATC_HasCASL ( HasCASL/ATC_HasCASL.hs,
 HasCASL/ATC_HasCASL.o )
 > ls -sh HasCASL/ATC_HasCASL.o
 732K HasCASL/ATC_HasCASL.o
 > ghc --version
 The Glorious Glasgow Haskell Compilation System, version 6.12.1
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3840#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 14:02:36 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 13:34:28 2010
Subject: [GHC] #2966: build system does not respect --with-gcc=
In-Reply-To: <045.38910ced362f70db06ad52953362394b@abbot.galois.com>
References: <045.38910ced362f70db06ad52953362394b@abbot.galois.com>
Message-ID: <054.1b58d90c98ba0f4d9e955c80dae6981b@abbot.galois.com>

#2966: build system does not respect --with-gcc=
----------------------------------+-----------------------------------------
  Reporter:  duncan               |          Owner:  igloo           
      Type:  merge                |         Status:  closed          
  Priority:  normal               |      Milestone:  6.12.2          
 Component:  Build System         |        Version:  6.12.1          
Resolution:  fixed                |       Keywords:                  
Difficulty:  Unknown              |             Os:  Unknown/Multiple
  Testcase:                       |   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------
Changes (by igloo):

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


Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2966#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 14:02:47 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 13:34:40 2010
Subject: [GHC] #3804: strange output of mkGHCConstants on SunOS 5.8/sparc
In-Reply-To: <042.aa6d3bd949f1a02a1e301e5062530c41@abbot.galois.com>
References: <042.aa6d3bd949f1a02a1e301e5062530c41@abbot.galois.com>
Message-ID: <051.23fe2faaa28674ea093fe855c9976704@abbot.galois.com>

#3804: strange output of mkGHCConstants on SunOS 5.8/sparc
----------------------------------+-----------------------------------------
  Reporter:  CBa                  |          Owner:  igloo  
      Type:  merge                |         Status:  closed 
  Priority:  normal               |      Milestone:  6.12.2 
 Component:  Build System         |        Version:  6.12.1 
Resolution:  fixed                |       Keywords:         
Difficulty:                       |             Os:  Solaris
  Testcase:                       |   Architecture:  sparc  
   Failure:  Building GHC failed  |  
----------------------------------+-----------------------------------------
Changes (by igloo):

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


Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3804#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 14:02:57 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 13:34:50 2010
Subject: [GHC] #3790: control-C causes segfault,
 siginfo_t* can be NULL on Solaris
In-Reply-To: <045.d2557c16e92c7f9e5e2306103fb1f846@abbot.galois.com>
References: <045.d2557c16e92c7f9e5e2306103fb1f846@abbot.galois.com>
Message-ID: <054.ee05ff5980458b69b4438b72118c92ec@abbot.galois.com>

#3790: control-C causes segfault, siginfo_t* can be NULL on Solaris
-----------------------------+----------------------------------------------
  Reporter:  duncan          |          Owner:  igloo  
      Type:  merge           |         Status:  closed 
  Priority:  normal          |      Milestone:  6.12.2 
 Component:  Runtime System  |        Version:  6.12.1 
Resolution:  fixed           |       Keywords:         
Difficulty:                  |             Os:  Solaris
  Testcase:                  |   Architecture:  sparc  
   Failure:  Runtime crash   |  
-----------------------------+----------------------------------------------
Changes (by igloo):

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


Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3790#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 14:03:11 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 13:35:03 2010
Subject: [GHC] #3803: addCoverageTicksTobind should not panic when file
 location is Nothing
In-Reply-To: <046.170aea52f7935907ca6deb8869a6f4be@abbot.galois.com>
References: <046.170aea52f7935907ca6deb8869a6f4be@abbot.galois.com>
Message-ID: <055.bbb746f88e3cab3a9c07ec29561ae264@abbot.galois.com>

#3803: addCoverageTicksTobind should not panic when file location is Nothing
---------------------------+------------------------------------------------
  Reporter:  clemens       |          Owner:  igloo           
      Type:  merge         |         Status:  closed          
  Priority:  high          |      Milestone:  6.12.2          
 Component:  Compiler      |        Version:  6.12.1          
Resolution:  fixed         |       Keywords:  hpc             
Difficulty:                |             Os:  Unknown/Multiple
  Testcase:                |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by igloo):

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


Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3803#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 14:03:48 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 13:35:39 2010
Subject: [GHC] #3793: System.Time.toClockTime does not support all valid
 timezone offsets.
In-Reply-To: <045.573376566b5efc770151c67d8f432e86@abbot.galois.com>
References: <045.573376566b5efc770151c67d8f432e86@abbot.galois.com>
Message-ID: <054.e335fd3e51b9d210613f939772428f55@abbot.galois.com>

#3793: System.Time.toClockTime does not support all valid timezone offsets.
------------------------------------------+---------------------------------
  Reporter:  daniel                       |          Owner:  igloo                  
      Type:  merge                        |         Status:  closed                 
  Priority:  high                         |      Milestone:  6.12.2                 
 Component:  libraries/old-time           |        Version:                         
Resolution:  fixed                        |       Keywords:  tz timezone toClockTime
Difficulty:  Easy (less than 1 hour)      |             Os:  Unknown/Multiple       
  Testcase:                               |   Architecture:  Unknown/Multiple       
   Failure:  Incorrect result at runtime  |  
------------------------------------------+---------------------------------
Changes (by igloo):

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


Comment:

 Merged as part of:
 {{{
 Wed Jan 27 08:03:07 PST 2010  Ian Lynagh <igloo@earth.li>
   * Update to new versions of hpc and old-time
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3793#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 14:04:34 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 13:36:25 2010
Subject: [GHC] #3821: Trace.Hpc.Reflect.examineTix segfaults on 64bit
In-Reply-To: <053.fbf59e92eb99357652de0927fec4376a@abbot.galois.com>
References: <053.fbf59e92eb99357652de0927fec4376a@abbot.galois.com>
Message-ID: <062.72ccc5bec88c32a060e4688d0477268c@abbot.galois.com>

#3821: Trace.Hpc.Reflect.examineTix segfaults on 64bit
-----------------------------+----------------------------------------------
  Reporter:  TristanAllwood  |          Owner:  igloo           
      Type:  merge           |         Status:  closed          
  Priority:  high            |      Milestone:  6.12.2          
 Component:  Code Coverage   |        Version:  6.12.1          
Resolution:  fixed           |       Keywords:                  
Difficulty:                  |             Os:  Unknown/Multiple
  Testcase:                  |   Architecture:  x86_64 (amd64)  
   Failure:  None/Unknown    |  
-----------------------------+----------------------------------------------
Changes (by igloo):

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


Comment:

 Merged as part of:
 {{{
 Wed Jan 27 08:03:07 PST 2010  Ian Lynagh <igloo@earth.li>
   * Update to new versions of hpc and old-time
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3821#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 15:14:49 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 14:46:53 2010
Subject: [GHC] #3840: ghc-6.12.1 takes longer to compile code and
 produces bigger binaries compared to ghc-6.10.4
In-Reply-To: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
References: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
Message-ID: <054.ef4c1cb3306bdfc114cdf4ea39873882@abbot.galois.com>

#3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries
compared to ghc-6.10.4
-------------------------+--------------------------------------------------
    Reporter:  maeder    |        Owner:              
        Type:  bug       |       Status:  new         
    Priority:  normal    |    Milestone:              
   Component:  Compiler  |      Version:  6.12.1      
    Keywords:            |   Difficulty:              
          Os:  Linux     |     Testcase:              
Architecture:  x86       |      Failure:  None/Unknown
-------------------------+--------------------------------------------------

Comment(by maeder):

 Replying to [comment:3 simonpj]:
 > Is it possible to try with HEAD?  It has the new inlining story, which
 has changed (yet again) the way in which instances are treated.  If it's
 different it'd be helpful to know.

 I've looked under http://www.haskell.org/ghc/dist/current/dist/
 The linux-distros do not work for me (missing libtinfo). The newest src-
 bundle is from 20100108.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3840#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 27 15:31:39 2010
From: trac at galois.com (GHC)
Date: Wed Jan 27 15:03:34 2010
Subject: [GHC] #3840: ghc-6.12.1 takes longer to compile code and
 produces bigger binaries compared to ghc-6.10.4
In-Reply-To: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
References: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com>
Message-ID: <054.e4e989fa46292e71b8457a04f13f82fc@abbot.galois.com>

#3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries
compared to ghc-6.10.4
-------------------------+--------------------------------------------------
    Reporter:  maeder    |        Owner:              
        Type:  bug       |       Status:  new         
    Priority:  normal    |    Milestone:              
   Component:  Compiler  |      Version:  6.12.1      
    Keywords:            |   Difficulty:              
          Os:  Linux     |     Testcase:              
Architecture:  x86       |      Failure:  None/Unknown
-------------------------+--------------------------------------------------

Comment(by maeder):

 btw, the sources are world-readable https://svn-agbkb.informatik.uni-
 bremen.de/Hets/trunk/ or http://trac.informatik.uni-
 bremen.de:8080/hets/browser/trunk

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3840#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 02:27:13 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 01:59:36 2010
Subject: [GHC] #3844: Undeprecate #include (in at least some circumstances)
Message-ID: <042.5b982471a1a08813e02c6c6a28134af7@abbot.galois.com>

#3844: Undeprecate #include (in at least some circumstances)
-------------------------------+--------------------------------------------
    Reporter:  cjs             |       Owner:                                   
        Type:  bug             |      Status:  new                              
    Priority:  normal          |   Component:  Compiler (FFI)                   
     Version:  6.12.1          |    Keywords:  #include deprecation             
          Os:  Linux           |    Testcase:                                   
Architecture:  x86_64 (amd64)  |     Failure:  Incorrect warning at compile-time
-------------------------------+--------------------------------------------
 The attached program generates a warning: "Warning: -#include is
 deprecated: No longer has any effect". However, if I remove the #include,
 it fails to compile with:


 {{{
 Fixes.hsc: In function ?main?:
 Fixes.hsc:29: error: ?SOL_SOCKET? undeclared (first use in this function)
 Fixes.hsc:29: error: (Each undeclared identifier is reported only once
 Fixes.hsc:29: error: for each function it appears in.)
 Fixes.hsc:29: error: ?SO_LINGER? undeclared (first use in this function)
 Fixes.hsc:37: error: invalid application of ?sizeof? to incomplete type
 ?struct linger?
 Fixes.hsc:40: error: invalid use of undefined type ?struct linger?
 Fixes.hsc:41: error: invalid use of undefined type ?struct linger?
 }}}

 Evidently it's not quite true that #include no longer has any effect.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3844>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 04:23:32 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 03:55:37 2010
Subject: [GHC] #3771: haddock: internal error: evacuate: strange closure
 type 19269
In-Reply-To: <045.5a5990fc01611a666ea323a5f0afc325@abbot.galois.com>
References: <045.5a5990fc01611a666ea323a5f0afc325@abbot.galois.com>
Message-ID: <054.10a97162f9caeba73d78547de791f0c0@abbot.galois.com>

#3771: haddock: internal error: evacuate: strange closure type 19269
-------------------------+--------------------------------------------------
    Reporter:  dbueno    |        Owner:                     
        Type:  bug       |       Status:  new                
    Priority:  normal    |    Milestone:  6.12 branch        
   Component:  Compiler  |      Version:  6.12.1             
    Keywords:            |   Difficulty:                     
          Os:  MacOS X   |     Testcase:                     
Architecture:  powerpc   |      Failure:  Building GHC failed
-------------------------+--------------------------------------------------

Comment(by abutterfield):

 I just got a very similar error from GHCi on 6.10.4 on Windows XP (it said
 i386_inknown_mingw32), expect
 it reported strange closure type 18375

 GHCi was idle at the time whilst I was editing a source file...

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3771#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 04:52:45 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 04:24:41 2010
Subject: [GHC] #3843: Merge plugins into HEAD
In-Reply-To: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>
References: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>
Message-ID: <055.a49e3be17122df78efed6682a87cf2c8@abbot.galois.com>

#3843: Merge plugins into HEAD
---------------------------------+------------------------------------------
    Reporter:  dreixel           |        Owner:  simonpj     
        Type:  task              |       Status:  new         
    Priority:  normal            |    Milestone:              
   Component:  Compiler          |      Version:  6.13        
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by batterseapower):

 Patch attached. NB: the patch is against a fairly old GHC at this point!

 My original comments with the patch are below this line:

 What's included:
 * Dynamic loading of Core passes
 * -plg command line flag to load plugins
 * -P PluginName:option command line flag to supply options to them
 * Support for using plugins which are not installed in the package DB
 (i.e. I have write a Plugin.hs and use it directly to compile Foo.hs
 in the same directory)
 * Tests for plugin system

 The annotation system and CoreMonad were already merged, so this patch is
 quite manageable.

 I've run the full testsuite against the tree, and there are no additional
 failures compared to HEAD.

 Outstanding issues:
 * Need updated documentation to reflect the new plugins story (no phase
 system). I'll write this if you approve of the new design for how plugins
 get installed.
 * It probably only works on OS X because I'm using Apple linker options to
 export package GHC from the GHC executable. We probably need shared
 library support before it works on Windows and Linux. However, I've
 guessed at some linker options that are suitable for those platforms (see
 ghc-bin), so there is a small possibility it will
 work.

 My two simple example plugins (strict-plugin, cse-plugin - available on
 code.haskell.org) both work correctly. My complex example plugin segfaults
 during compilation, but this has always been true. I am not sure how to
 debug this, and it might be related to my linker hacks. For this reason it
 might be best to merge the plugins patch so I can stop maintaining the
 branch but keep it on the down-low until we find some time to sort this
 out AFTER shared libaries are in.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3843#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 04:54:27 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 04:26:22 2010
Subject: [GHC] #3843: Merge plugins into HEAD
In-Reply-To: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>
References: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>
Message-ID: <055.3076ab26f4fd60d428460037b41052cd@abbot.galois.com>

#3843: Merge plugins into HEAD
---------------------------------+------------------------------------------
    Reporter:  dreixel           |        Owner:  simonpj     
        Type:  task              |       Status:  new         
    Priority:  normal            |    Milestone:              
   Component:  Compiler          |      Version:  6.13        
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by batterseapower):

 * cc: batterseapower@? (added)


Comment:

 Actually, there is a file size limit of 256kB so I can't attach it.

 I've restored the patches to a URL at the Cambridge computer lab though:
 http://www.cl.cam.ac.uk/~mb566/files/Plugins-Patches.zip

 (The testsuite patch is 75MB for some reason!)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3843#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 05:53:26 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 05:25:45 2010
Subject: [GHC] #3844: Undeprecate #include (in at least some
 circumstances)
In-Reply-To: <042.5b982471a1a08813e02c6c6a28134af7@abbot.galois.com>
References: <042.5b982471a1a08813e02c6c6a28134af7@abbot.galois.com>
Message-ID: <051.89a2228d04c5e52bb0b9ec40b13b2bb8@abbot.galois.com>

#3844: Undeprecate #include (in at least some circumstances)
-------------------------------------+--------------------------------------
    Reporter:  cjs                   |        Owner:                                   
        Type:  bug                   |       Status:  new                              
    Priority:  normal                |    Milestone:  6.14.1                           
   Component:  Compiler (FFI)        |      Version:  6.12.1                           
    Keywords:  #include deprecation  |   Difficulty:                                   
          Os:  Unknown/Multiple      |     Testcase:                                   
Architecture:  Unknown/Multiple      |      Failure:  Incorrect warning at compile-time
-------------------------------------+--------------------------------------
Changes (by simonmar):

  * os:  Linux => Unknown/Multiple
  * architecture:  x86_64 (amd64) => Unknown/Multiple
  * milestone:  => 6.14.1


Comment:

 So the problem here is that `hsc2hs` is generating the `{-# INCLUDE #-}`
 pragma, because it doesn't know which version of GHC you're going to use
 to compile the resulting `.hs` file.  If we fixed #3457, then we could fix
 this ticket too.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3844#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 05:54:04 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 05:25:53 2010
Subject: [GHC] #3457: Impossible to specify pragmas compatible with
 multiple ghc versions
In-Reply-To: <045.b42d9302a58a1a0f28ab9ef59d342a90@abbot.galois.com>
References: <045.b42d9302a58a1a0f28ab9ef59d342a90@abbot.galois.com>
Message-ID: <054.cd4528458de68517e42bed43c510c63f@abbot.galois.com>

#3457: Impossible to specify pragmas compatible with multiple ghc versions
---------------------------------+------------------------------------------
    Reporter:  duncan            |        Owner:                            
        Type:  bug               |       Status:  new                       
    Priority:  normal            |    Milestone:  6.14.1                    
   Component:  Driver            |      Version:  6.10.4                    
    Keywords:                    |   Difficulty:  Moderate (less than a day)
          Os:  Unknown/Multiple  |     Testcase:                            
Architecture:  Unknown/Multiple  |      Failure:  GHC rejects valid program 
---------------------------------+------------------------------------------

Comment(by simonmar):

 See also #3844, which depends on this being fixed.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3457#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 06:00:09 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 05:32:21 2010
Subject: [GHC] #3771: haddock: internal error: evacuate: strange closure
 type 19269
In-Reply-To: <045.5a5990fc01611a666ea323a5f0afc325@abbot.galois.com>
References: <045.5a5990fc01611a666ea323a5f0afc325@abbot.galois.com>
Message-ID: <054.6fe122e73a4807502b97b5c636e0f082@abbot.galois.com>

#3771: haddock: internal error: evacuate: strange closure type 19269
-------------------------+--------------------------------------------------
    Reporter:  dbueno    |        Owner:                     
        Type:  bug       |       Status:  new                
    Priority:  normal    |    Milestone:  6.12 branch        
   Component:  Compiler  |      Version:  6.12.1             
    Keywords:            |   Difficulty:                     
          Os:  MacOS X   |     Testcase:                     
Architecture:  powerpc   |      Failure:  Building GHC failed
-------------------------+--------------------------------------------------

Comment(by simonmar):

 The error "strange closure type" indicates some kind of memory corruption,
 which can have many different causes, from bugs in the GC to hardware
 failures.

 It's unlikely that the occurrence on Win XP is related to original report
 in this ticket, which I suspect is something specific to GHC's powerpc
 support (there are a few other similar reports of problems on powerpc).

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3771#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 06:02:37 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 05:34:29 2010
Subject: [GHC] #3756: Missing -lz option in testsuite
In-Reply-To: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com>
References: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com>
Message-ID: <065.003d1edf80f23a51045a5c2f226cbf71@abbot.galois.com>

#3756: Missing -lz option in testsuite
--------------------------------+-------------------------------------------
  Reporter:  daniel.is.fischer  |           Type:  bug         
    Status:  new                |       Priority:  normal      
 Milestone:  6.12.2             |      Component:  Build System
   Version:  6.12.1             |       Keywords:              
Difficulty:                     |             Os:  Linux       
  Testcase:                     |   Architecture:  x86         
   Failure:  Other              |  
--------------------------------+-------------------------------------------

Comment(by simonmar):

 and can you try running `ldd` on your `libbfd-2.19.so`?  Mine says:

 {{{
 $ ldd /usr/lib64/libbfd-2.18.50.0.6-2.so
         linux-vdso.so.1 =>  (0x00007fffa61fe000)
         libc.so.6 => /lib64/libc.so.6 (0x0000003c09a00000)
         /lib64/ld-linux-x86-64.so.2 (0x0000003c09600000)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3756#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 06:28:28 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 06:00:17 2010
Subject: [GHC] #3763: make -j8 fails for ghc-6.12.1-pre
In-Reply-To: <050.b26e3f92f1a36f0cfca8f8ddeac68929@abbot.galois.com>
References: <050.b26e3f92f1a36f0cfca8f8ddeac68929@abbot.galois.com>
Message-ID: <059.e43c05f02e3011d559ed80e100e429ea@abbot.galois.com>

#3763: make -j8 fails for ghc-6.12.1-pre
---------------------------+------------------------------------------------
  Reporter:  juhpetersen   |          Owner:        
      Type:  bug           |         Status:  closed
  Priority:  normal        |      Milestone:  6.12.2
 Component:  Build System  |        Version:  6.12.1
Resolution:  worksforme    |       Keywords:        
Difficulty:                |             Os:  Linux 
  Testcase:                |   Architecture:  x86   
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by simonmar):

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


Comment:

 No response from submitter, and I can't make it fail here.  I have seen a
 problem where multiple `ghc-pkg` invocations trip over each other, but I
 can't seem to repeat it now.  Let's close this ticket and re-open it (or a
 new one) if the problem reappears.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3763#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 07:18:42 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 06:50:42 2010
Subject: [GHC] #3748: Bug in rts/Win32/Ticker.c can cause process hang
 on exit in Win32
In-Reply-To: <042.ebc1303ba4ba1bb01245ae57d2b8c614@abbot.galois.com>
References: <042.ebc1303ba4ba1bb01245ae57d2b8c614@abbot.galois.com>
Message-ID: <051.34739d275dbf42389a4dd5062709cba3@abbot.galois.com>

#3748: Bug in rts/Win32/Ticker.c can cause process hang on exit in Win32
---------------------------------+------------------------------------------
    Reporter:  sgf               |        Owner:  igloo        
        Type:  merge             |       Status:  new          
    Priority:  normal            |    Milestone:  6.12.2       
   Component:  Runtime System    |      Version:  6.10.4       
    Keywords:                    |   Difficulty:               
          Os:  Windows           |     Testcase:               
Architecture:  Unknown/Multiple  |      Failure:  Runtime crash
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * status:  assigned => new
  * type:  bug => merge


Comment:

 Fixed:

 {{{
 Wed Jan 27 13:54:30 GMT 2010  Simon Marlow <marlowsd@gmail.com>
   * Don't Terminate the ticker thread (#3748)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3748#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 07:22:07 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 06:53:58 2010
Subject: [GHC] #3656: ghci leaves /tmp/ghc* directory if killed by signal
In-Reply-To: <042.d95f8802b8c0b09855d12a49e63b7a91@abbot.galois.com>
References: <042.d95f8802b8c0b09855d12a49e63b7a91@abbot.galois.com>
Message-ID: <051.d385ef8dad5fc79068a9f96b9fad7e14@abbot.galois.com>

#3656: ghci leaves /tmp/ghc* directory if killed by signal
---------------------------------+------------------------------------------
    Reporter:  vvv               |        Owner:  igloo       
        Type:  merge             |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  GHCi              |      Version:  6.10.4      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by simonmar):

 this patch needs to be merge too:

 {{{
 Wed Jan 27 16:29:54 GMT 2010  Simon Marlow <marlowsd@gmail.com>
   * fix warning on Windows
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3656#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 08:42:18 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 08:14:08 2010
Subject: [GHC] #3756: Missing -lz option in testsuite
In-Reply-To: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com>
References: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com>
Message-ID: <065.e1e4011b505d69d07a36c89dcb55c2b4@abbot.galois.com>

#3756: Missing -lz option in testsuite
--------------------------------+-------------------------------------------
  Reporter:  daniel.is.fischer  |           Type:  bug         
    Status:  new                |       Priority:  normal      
 Milestone:  6.12.2             |      Component:  Build System
   Version:  6.12.1             |       Keywords:              
Difficulty:                     |             Os:  Linux       
  Testcase:                     |   Architecture:  x86         
   Failure:  Other              |  
--------------------------------+-------------------------------------------

Comment(by daniel.is.fischer):

 Mine says
 {{{
 $ ldd /usr/lib/libbfd-2.19.so
         linux-gate.so.1 =>  (0xffffe000)
         /usr/lib/libv4l/v4l2convert.so (0xb7618000)
         libz.so.1 => /lib/libz.so.1 (0xb75da000)
         libc.so.6 => /lib/libc.so.6 (0xb747e000)
         libv4l2.so.0 => /usr/lib/libv4l2.so.0 (0xb7474000)
         /lib/ld-linux.so.2 (0xb789c000)
         libv4lconvert.so.0 => /usr/lib/libv4lconvert.so.0 (0xb740e000)
         libpthread.so.0 => /lib/libpthread.so.0 (0xb73f4000)
 }}}
 Yep,definitely depends on libz.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3756#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 09:48:29 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 09:20:18 2010
Subject: [GHC] #2797: ghci stack overflows when ghc does not
In-Reply-To: <053.b5bed6c883dfb7d157e5092dcf2242ee@abbot.galois.com>
References: <053.b5bed6c883dfb7d157e5092dcf2242ee@abbot.galois.com>
Message-ID: <062.4c8601bb0545fe026ef46fb76c145b74@abbot.galois.com>

#2797: ghci stack overflows when ghc does not
---------------------------------+------------------------------------------
    Reporter:  TristanAllwood    |        Owner:  igloo                  
        Type:  merge             |       Status:  new                    
    Priority:  normal            |    Milestone:  6.12.2                 
   Component:  GHCi              |      Version:  6.11                   
    Keywords:                    |   Difficulty:  Unknown                
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  => igloo
  * type:  bug => merge


Comment:

 Fixed (sort of):

 {{{
 Thu Jan 28 12:44:54 GMT 2010  Simon Marlow <marlowsd@gmail.com>
   * tweak the totally-bogus arbitrary stack-squeezing heuristic to fix
 #2797
   In #2797, a program that ran in constant stack space when compiled
   needed linear stack space when interpreted.  It turned out to be
   nothing more than stack-squeezing not happening.  We have a heuristic
   to avoid stack-squeezing when it would be too expensive (shuffling a
   large amount of memory to save a few words), but in some cases even
   expensive stack-squeezing is necessary to avoid linear stack usage.
   One day we should implement stack chunks, which would make this less
   expensive.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2797#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 10:27:52 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 09:59:43 2010
Subject: [GHC] #3726: Internal error compiling ghc-syb-0.1.2.1
In-Reply-To: <052.a180cd251b9bcdf1661af16494dfc00b@abbot.galois.com>
References: <052.a180cd251b9bcdf1661af16494dfc00b@abbot.galois.com>
Message-ID: <061.6d4672d87ae29694e0de96e1422b9586@abbot.galois.com>

#3726: Internal error compiling ghc-syb-0.1.2.1
---------------------------------+------------------------------------------
  Reporter:  DavidHalperin       |          Owner:                  
      Type:  bug                 |         Status:  closed          
  Priority:  normal              |      Milestone:  6.12.2          
 Component:  Compiler            |        Version:  6.10.4          
Resolution:  worksforme          |       Keywords:                  
Difficulty:                      |             Os:  Unknown/Multiple
  Testcase:                      |   Architecture:  Unknown/Multiple
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Changes (by simonmar):

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


Comment:

 I can't repeat this - same platform, same GHC version.  Please re-open if
 it happens again, and try to see if you can make it happen repeatably
 (preferably on more than one machine).

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3726#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 12:01:55 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 11:33:44 2010
Subject: [GHC] #3845: compiling template haskell internal error: ... not in
 scope during type checking, but it passed the renamer
Message-ID: <048.f5696685aefedadc5457b44787ff59f6@abbot.galois.com>

#3845: compiling template haskell internal error: ... not in scope during type
checking, but it passed the renamer
---------------------------------+------------------------------------------
    Reporter:  JakeWheat         |       Owner:              
        Type:  bug               |      Status:  new         
    Priority:  normal            |   Component:  Compiler    
     Version:  6.12.1            |    Keywords:              
          Os:  Unknown/Multiple  |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------
 example code:
 {{{
 {-# LANGUAGE TemplateHaskell #-}

 module THBug1 where

 import Language.Haskell.TH

 data HCons a b = HCons a b
 data HNil = HNil

 mhlt :: [Type] -> Q Type
 mhlt xss = [t| $(foldThing xss)|]
   where
     foldThing (x:xs) = [t| HCons $x $(foldThing xs)|]
     foldThing [] = [t| HNil |]
 }}}
 compiling gives:
 {{{
 ~$ ghc -c THBug1.hs

 THBug1.hs:13:38:
     GHC internal error: `foldThing' is not in scope during type checking,
 but it passed the renamer
     tcg_type_env of environment: [(rge, Type constructor `HNil'),
                                   (rgg, Data constructor `HNil'), (rgi,
 Type constructor `HCons'),
                                   (rgk, Data constructor `HCons'), (rgJ,
 Identifier `THBug1.HNil'),
                                   (rgM, Identifier `THBug1.HCons')]
     In the expression: foldThing xs
     In the Template Haskell quotation [t| HCons $x $(foldThing xs) |]
     In the expression: [t| HCons $x $(foldThing xs) |]
 }}}

 ghc used is the latest ghc 6.12.1 from debian experimental (package
 version 6.1.12-3, which is latest as of 28 Jan)

 further details:

 {{{
 ~$ uname -a
 Linux debiannew 2.6.32-trunk-686-bigmem #1 SMP Sun Jan 10 07:12:17 UTC
 2010 i686 GNU/Linux
 ~$ gcc -v
 Using built-in specs.
 Target: i486-linux-gnu
 Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.3-1'
 --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-
 languages=c,c++,fortran,objc,obj-c++
 --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id
 --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
 --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-
 libstdcxx-debug
 --enable-objc-gc --enable-targets=all --with-arch-32=i486 --with-
 tune=generic
 --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
 --target=i486-linux-gnu
 Thread model: posix
 gcc version 4.4.3 (Debian 4.4.3-1)
 ~$ ghc -c -v -dcore-lint THBug1.hs
 Glasgow Haskell Compiler, Version 6.12.1, for Haskell 98, stage 2 booted
 by GHC version 6.12.1
 Using binary package database:
 /usr/lib/ghc-6.12.1/package.conf.d/package.cache
 Using binary package database:
 /home/jake/.ghc/i386-linux-6.12.1/package.conf.d/package.cache
 hiding package QuickCheck-1.2.0.0 to avoid conflict with later version
 QuickCheck-2.1.0.3
 hiding package base-3.0.3.2 to avoid conflict with later version
 base-4.2.0.0
 hiding package parsec-2.1.0.1 to avoid conflict with later version
 parsec-3.0.1
 wired-in package ghc-prim mapped to ghc-
 prim-0.2.0.0-3fbcc20c802efcd7c82089ec77d92990
 wired-in package integer-gmp mapped to integer-
 gmp-0.2.0.0-fa82a0df93dc30b4a7c5654dd7c68cf4
 wired-in package base mapped to
 base-4.2.0.0-73995e854f236dc2acd577d7c791221d
 wired-in package rts mapped to builtin_rts
 wired-in package haskell98 mapped to
 haskell98-1.0.1.1-0fdaf3b26bc38c43ce8371edf538dbf6
 wired-in package template-haskell mapped to template-
 haskell-2.4.0.0-92d419f5a3bd03d1c021561d3b29c041
 wired-in package dph-seq mapped to dph-
 seq-0.4.0-1f5167ea371010387123b68e975177b2
 wired-in package dph-par mapped to dph-
 par-0.4.0-4e569f28e047d67d87266113526bc6ec
 Hsc static flags: -static
 Created temporary directory: /tmp/ghc19231_0
 *** Checking old interface for main:THBug1:
 *** Parser:
 *** Renamer/typechecker:

 THBug1.hs:13:38:
     GHC internal error: `foldThing' is not in scope during type checking,
 but it passed the renamer
     tcg_type_env of environment: [(rge, Type constructor `HNil'),
                                   (rgg, Data constructor `HNil'), (rgi,
 Type constructor `HCons'),
                                   (rgk, Data constructor `HCons'), (rgJ,
 Identifier `THBug1.HNil'),
                                   (rgM, Identifier `THBug1.HCons')]
     In the expression: foldThing xs
     In the Template Haskell quotation [t| HCons $x $(foldThing xs) |]
     In the expression: [t| HCons $x $(foldThing xs) |]
 *** Deleting temp files:
 Deleting: /tmp/ghc19231_0/ghc19231_0.s
 Warning: deleting non-existent /tmp/ghc19231_0/ghc19231_0.s
 *** Deleting temp dirs:
 Deleting: /tmp/ghc19231_0
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3845>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 18:17:18 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 17:49:12 2010
Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern
 checking
In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@abbot.galois.com>
References: <047.bea78f01cbb904765ad77c751bc8d3af@abbot.galois.com>
Message-ID: <056.2f03eae056d048b4970cc06c8fc137a0@abbot.galois.com>

#595: Overhaul GHC's overlapping/non-exhaustive pattern checking
------------------------------------------------+---------------------------
  Reporter:  simonmar                           |          Owner:  marcotmarcot    
      Type:  task                               |         Status:  new             
  Priority:  normal                             |      Milestone:  _|_             
 Component:  Compiler                           |        Version:  None            
Resolution:  None                               |       Keywords:  warnings        
Difficulty:  Difficult (2-5 days)               |             Os:  Unknown/Multiple
  Testcase:  N/A                                |   Architecture:  Unknown/Multiple
   Failure:  Incorrect warning at compile-time  |  
------------------------------------------------+---------------------------
Changes (by marcotmarcot):

  * owner:  => marcotmarcot


Comment:

 I'm studying the source code related to the bug, and I have read the
 [http://pauillac.inria.fr/~maranget/papers/warn/index.html pointed paper].
 I'm
 [http://www2.dcc.ufmg.br/laboratorios/llp/wiki/doku.php?id=pattern_matching_in_ghc
 describing my progress in this page].

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/595#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 18:31:46 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 18:03:34 2010
Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern
 checking
In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@abbot.galois.com>
References: <047.bea78f01cbb904765ad77c751bc8d3af@abbot.galois.com>
Message-ID: <056.9bf78acc8f2e50fb75029cf1fd6809e3@abbot.galois.com>

#595: Overhaul GHC's overlapping/non-exhaustive pattern checking
------------------------------------------------+---------------------------
  Reporter:  simonmar                           |          Owner:  marcotmarcot    
      Type:  task                               |         Status:  new             
  Priority:  normal                             |      Milestone:  _|_             
 Component:  Compiler                           |        Version:  None            
Resolution:  None                               |       Keywords:  warnings        
Difficulty:  Difficult (2-5 days)               |             Os:  Unknown/Multiple
  Testcase:  N/A                                |   Architecture:  Unknown/Multiple
   Failure:  Incorrect warning at compile-time  |  
------------------------------------------------+---------------------------

Comment(by simonpj):

 Excellent!  Please also consult http://www.cs.cmu.edu/~neelk/pattern-
 popl09.pdf

 Also do not forget about view patterns

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/595#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 19:09:01 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 18:40:53 2010
Subject: [GHC] #3843: Merge plugins into HEAD
In-Reply-To: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>
References: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com>
Message-ID: <055.4bd46623136d7928474cfeac28f773a7@abbot.galois.com>

#3843: Merge plugins into HEAD
---------------------------------+------------------------------------------
    Reporter:  dreixel           |        Owner:  simonpj     
        Type:  task              |       Status:  new         
    Priority:  normal            |    Milestone:              
   Component:  Compiler          |      Version:  6.13        
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by simonpj):

 Here's a link describing how Scala suppports plugins: http://www.scala-
 lang.org/node/140

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3843#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 28 22:28:57 2010
From: trac at galois.com (GHC)
Date: Thu Jan 28 22:00:45 2010
Subject: [GHC] #3846: .ghci file is ignored on Mac OS X
Message-ID: <046.8eef4df2140a161a09f528ad32c120bd@abbot.galois.com>

#3846: .ghci file is ignored on Mac OS X
------------------------+---------------------------------------------------
    Reporter:  mvanier  |       Owner:       
        Type:  bug      |      Status:  new  
    Priority:  normal   |   Component:  GHCi 
     Version:  6.10.4   |    Keywords:       
          Os:  MacOS X  |    Testcase:       
Architecture:  x86      |     Failure:  Other
------------------------+---------------------------------------------------
 I'm running ghc 6.10.4 on Mac OS X, and no matter what I do, my .ghci file
 is completely ignored.  Even if I put .ghci in the same directory I'm
 invoking ghci from, all the commands are ignored.  Other than that, as far
 as I can tell, ghci works fine.  My .ghci file contains only these lines:

 :set -fglasgow-exts -W

 :set -v0

 I can invoke these options successfully by calling ghci with the options
 enabled, but I'd rather use a .ghci file.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3846>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 29 02:53:46 2010
From: trac at galois.com (GHC)
Date: Fri Jan 29 02:25:39 2010
Subject: [GHC] #3817: mangler fails with gcc-4.3.x and gcc-4.1.2 on
 sparc; suggest disabling -fvia-C (was: -fvia-C / mangler fails with
 gcc-4.3.x on sparc; suggest disabling -fvia-C)
In-Reply-To: <045.763dbbac5925c7bf65ed54ed1092e47b@abbot.galois.com>
References: <045.763dbbac5925c7bf65ed54ed1092e47b@abbot.galois.com>
Message-ID: <054.19323a81dd66247437454784be8286ef@abbot.galois.com>

#3817: mangler fails with gcc-4.3.x and gcc-4.1.2 on sparc; suggest disabling
-fvia-C
---------------------------------+------------------------------------------
    Reporter:  duncan            |        Owner:                         
        Type:  bug               |       Status:  new                    
    Priority:  low               |    Milestone:  6.12.2                 
   Component:  Driver            |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:  Easy (less than 1 hour)
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  sparc             |      Failure:  Runtime crash          
---------------------------------+------------------------------------------

Comment(by benl):

 The mangler also fails with GCC 4.1.2 on {{{integer-gmp/cbits/gmp-
 wrappers.cmm}}}, probably because it's hand written cmm code and not
 produced by GHC proper.

 At this point in time, we have a working GHC 6.10.1 binary distro, with a
 broken {{{-fasm}}} and the head with a broken {{{-fvia-c}}}. Bootstrapping
 the head with 6.10.1 requires the following carefully staged build
 options:

 {{{
 SRC_HC_OPTS     = -O0 -fvia-c -H64m
 GhcStage1HcOpts = -O
 GhcStage2HcOpts = -O0 -fasm
 GhcHcOpts       = -Rghc-timing
 GhcLibHcOpts    = -O0 -fasm -XGenerics
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3817#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 29 05:25:22 2010
From: trac at galois.com (GHC)
Date: Fri Jan 29 04:57:08 2010
Subject: [GHC] #2464: Allow #ifdef'd pragmas
In-Reply-To: <042.da2d7162b5833ab052aba0dee11396e7@abbot.galois.com>
References: <042.da2d7162b5833ab052aba0dee11396e7@abbot.galois.com>
Message-ID: <051.fbd3720c81acaee525a22289ec2877ee@abbot.galois.com>

#2464: Allow #ifdef'd pragmas
---------------------------------+------------------------------------------
    Reporter:  ajd               |        Owner:  simonmar                  
        Type:  bug               |       Status:  assigned                  
    Priority:  normal            |    Milestone:  6.14.1                    
   Component:  Driver            |      Version:  6.8.2                     
    Keywords:                    |   Difficulty:  Moderate (less than a day)
          Os:  Unknown/Multiple  |     Testcase:                            
Architecture:  Unknown/Multiple  |      Failure:  GHC rejects valid program 
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar
  * status:  new => assigned


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2464#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 29 07:20:04 2010
From: trac at galois.com (GHC)
Date: Fri Jan 29 06:51:50 2010
Subject: [GHC] #2464: Allow #ifdef'd pragmas
In-Reply-To: <042.da2d7162b5833ab052aba0dee11396e7@abbot.galois.com>
References: <042.da2d7162b5833ab052aba0dee11396e7@abbot.galois.com>
Message-ID: <051.40709fe92b286d88dc8cfd5fc839a4b7@abbot.galois.com>

#2464: Allow #ifdef'd pragmas
---------------------------------+------------------------------------------
    Reporter:  ajd               |        Owner:  simonmar                  
        Type:  bug               |       Status:  assigned                  
    Priority:  normal            |    Milestone:  6.14.1                    
   Component:  Driver            |      Version:  6.8.2                     
    Keywords:                    |   Difficulty:  Moderate (less than a day)
          Os:  Unknown/Multiple  |     Testcase:                            
Architecture:  Unknown/Multiple  |      Failure:  GHC rejects valid program 
---------------------------------+------------------------------------------

Comment(by simonmar):

 Fixed:

 {{{
 Fri Jan 29 03:40:50 PST 2010  Simon Marlow <marlowsd@gmail.com>
   * Re-read pragmas after preprocessing (#2464, #3674, #3457)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2464#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 29 07:20:12 2010
From: trac at galois.com (GHC)
Date: Fri Jan 29 06:51:57 2010
Subject: [GHC] #2464: Allow #ifdef'd pragmas
In-Reply-To: <042.da2d7162b5833ab052aba0dee11396e7@abbot.galois.com>
References: <042.da2d7162b5833ab052aba0dee11396e7@abbot.galois.com>
Message-ID: <051.a0dbc4eddf259f88de2b2d331d5ecfe8@abbot.galois.com>

#2464: Allow #ifdef'd pragmas
-----------------------------------------+----------------------------------
  Reporter:  ajd                         |          Owner:  simonmar        
      Type:  bug                         |         Status:  closed          
  Priority:  normal                      |      Milestone:  6.14.1          
 Component:  Driver                      |        Version:  6.8.2           
Resolution:  fixed                       |       Keywords:                  
Difficulty:  Moderate (less than a day)  |             Os:  Unknown/Multiple
  Testcase:                              |   Architecture:  Unknown/Multiple
   Failure:  GHC rejects valid program   |  
-----------------------------------------+----------------------------------
Changes (by simonmar):

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


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2464#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 29 07:20:40 2010
From: trac at galois.com (GHC)
Date: Fri Jan 29 06:52:26 2010
Subject: [GHC] #3674: Recognise language pragmas generated by custom
 pre-processors (run with -F)
In-Reply-To: <047.f133953f7994cae1dfd3e6f2c8e5d7e7@abbot.galois.com>
References: <047.f133953f7994cae1dfd3e6f2c8e5d7e7@abbot.galois.com>
Message-ID: <056.76cc4a7a58828df0f6aefcdbb5f02b2f@abbot.galois.com>

#3674: Recognise language pragmas generated by custom pre-processors (run with -F)
-----------------------------------------+----------------------------------
  Reporter:  dorchard                    |          Owner:  simonmar              
      Type:  bug                         |         Status:  closed                
  Priority:  normal                      |      Milestone:  6.14.1                
 Component:  Driver                      |        Version:                        
Resolution:  fixed                       |       Keywords:  customer pre-processor
Difficulty:  Moderate (less than a day)  |             Os:  Unknown/Multiple      
  Testcase:                              |   Architecture:  Unknown/Multiple      
   Failure:  GHC rejects valid program   |  
-----------------------------------------+----------------------------------
Changes (by simonmar):

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


Comment:

 Fixed:

 {{{
 Fri Jan 29 03:40:50 PST 2010  Simon Marlow <marlowsd@gmail.com>
   * Re-read pragmas after preprocessing (#2464, #3674, #3457)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3674#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 29 07:21:21 2010
From: trac at galois.com (GHC)
Date: Fri Jan 29 06:53:07 2010
Subject: [GHC] #3457: Impossible to specify pragmas compatible with
 multiple ghc versions
In-Reply-To: <045.b42d9302a58a1a0f28ab9ef59d342a90@abbot.galois.com>
References: <045.b42d9302a58a1a0f28ab9ef59d342a90@abbot.galois.com>
Message-ID: <054.d87cb7f404f939303b3375b9e7b500fb@abbot.galois.com>

#3457: Impossible to specify pragmas compatible with multiple ghc versions
-----------------------------------------+----------------------------------
  Reporter:  duncan                      |          Owner:                  
      Type:  bug                         |         Status:  closed          
  Priority:  normal                      |      Milestone:  6.14.1          
 Component:  Driver                      |        Version:  6.10.4          
Resolution:  fixed                       |       Keywords:                  
Difficulty:  Moderate (less than a day)  |             Os:  Unknown/Multiple
  Testcase:                              |   Architecture:  Unknown/Multiple
   Failure:  GHC rejects valid program   |  
-----------------------------------------+----------------------------------
Changes (by simonmar):

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


Comment:

 Fixed:

 {{{
 Fri Jan 29 03:40:50 PST 2010  Simon Marlow <marlowsd@gmail.com>
   * Re-read pragmas after preprocessing (#2464, #3674, #3457)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3457#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 29 10:20:29 2010
From: trac at galois.com (GHC)
Date: Fri Jan 29 09:52:15 2010
Subject: [GHC] #3847: Windows installer has incorrect documentation shortcut
Message-ID: <051.dbb06debb35b6c2c5d7b37d30c3d1f07@abbot.galois.com>

#3847: Windows installer has incorrect documentation shortcut
---------------------------------+------------------------------------------
    Reporter:  NeilMitchell      |       Owner:                   
        Type:  bug               |      Status:  new              
    Priority:  normal            |   Component:  Compiler         
     Version:  6.12.1            |    Keywords:                   
          Os:  Windows           |    Testcase:                   
Architecture:  Unknown/Multiple  |     Failure:  Documentation bug
---------------------------------+------------------------------------------
 With the Windows install of 6.12.1, the link on the start menu at
 GHC/6.12.1/Documentation points at
 file:///C:/ghc/ghc-6.12.1/doc/index.html, when the documentation is really
 located at file:///C:/ghc/ghc-6.12.1/doc/html/index.html. All the other
 documentation links are similarly incorrect.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3847>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 29 12:17:17 2010
From: trac at galois.com (GHC)
Date: Fri Jan 29 11:49:06 2010
Subject: [GHC] #594: Support use of SSE2 in the x86 native code genreator
In-Reply-To: <047.5190f55d4ad1363b95d98c092787782f@abbot.galois.com>
References: <047.5190f55d4ad1363b95d98c092787782f@abbot.galois.com>
Message-ID: <056.c3384221ed8028185e226d4023a2025a@abbot.galois.com>

#594: Support use of SSE2 in the x86 native code genreator
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  simonmar                  
        Type:  task              |       Status:  assigned                  
    Priority:  normal            |    Milestone:  6.14.1                    
   Component:  Compiler (NCG)    |      Version:  6.4.1                     
    Keywords:                    |   Difficulty:  Moderate (less than a day)
          Os:  Unknown/Multiple  |     Testcase:  N/A                       
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug   
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar
  * status:  new => assigned
  * milestone:  6.12 branch => 6.14.1


Comment:

 I'm on this.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/594#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 29 21:29:33 2010
From: trac at galois.com (GHC)
Date: Fri Jan 29 21:01:17 2010
Subject: [GHC] #3848: Error message typo in rts/RtsAPI.c
Message-ID: <044.0702ff6eeab4c6d918d0c693dbbdade1@abbot.galois.com>

#3848: Error message typo in rts/RtsAPI.c
---------------------------------+------------------------------------------
    Reporter:  larsv             |       Owner:                
        Type:  bug               |      Status:  new           
    Priority:  normal            |   Component:  Runtime System
     Version:  6.12.1            |    Keywords:                
          Os:  Unknown/Multiple  |    Testcase:                
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown  
---------------------------------+------------------------------------------
 In rts/RtsAPI.c in the error message about re-entrant finalizers for
 !ForeignPtrs, there is a misspelling of Haskell as Haskll.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3848>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 30 04:09:25 2010
From: trac at galois.com (GHC)
Date: Sat Jan 30 03:41:11 2010
Subject: [GHC] #2451: New signal-handling API
In-Reply-To: <047.5b7641d67bfb4c219c1a85428fd85097@abbot.galois.com>
References: <047.5b7641d67bfb4c219c1a85428fd85097@abbot.galois.com>
Message-ID: <056.933e389c82989c51d16aaf32c8b33ffb@abbot.galois.com>

#2451: New signal-handling API
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  simonmar    
        Type:  proposal          |       Status:  new         
    Priority:  high              |    Milestone:  6.14 branch 
   Component:  libraries/unix    |      Version:  6.8.3       
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by simonmar):

  * failure:  => None/Unknown


Old description:

> The current API for handling signals in `System.Posix` is lacking in a
> couple of ways:
>
>  * it isn't modular: there's no way for a library to install a private
> signal handler,
>    there is only a singla global handler per signal.
>
>  * it isn't possible to get hold of the information from `siginfo_t`
> (#592).
>
> I want to propose a new API.  This has already undergone a round of
> changes after discussion with Duncan Coutts, and we ended up with
> something quite simple.  Haddock docs are here:
>
> [http://darcs.haskell.org/~simonmar/unix/System-Posix-Signals.html#4]
>
> (also attached as `unix-html.tar.gz`).
>
> I have working patches to implement this.  The old API is still
> available, and is reimplemented using the new API.  Signal handlers
> installed using the old API will coexist with those installed using the
> new API.
>
> The main motivation for this change was so that I could hook the
> `SIGCHLD` signal in the `System.Process` library without disturbing users
> of the `System.Posix` library who might also want to install a `SIGCHLD`
> handler.
>
> Deadline: 1 Aug (2 weeks)

New description:

 The current API for handling signals in `System.Posix` is lacking in a
 couple of ways:

  * it isn't modular: there's no way for a library to install a private
 signal handler,
    there is only a singla global handler per signal.

  * it isn't possible to get hold of the information from `siginfo_t`
 (#592).

 I want to propose a new API.  This has already undergone a round of
 changes after discussion with Duncan Coutts, and we ended up with
 something quite simple.  Haddock docs are here:

 [http://www.haskell.org/~simonmar/unix/System-Posix-Signals.html#4]

 (also attached as `unix-html.tar.gz`).

 I have working patches to implement this.  The old API is still available,
 and is reimplemented using the new API.  Signal handlers installed using
 the old API will coexist with those installed using the new API.

 The main motivation for this change was so that I could hook the `SIGCHLD`
 signal in the `System.Process` library without disturbing users of the
 `System.Posix` library who might also want to install a `SIGCHLD` handler.

 Deadline: 1 Aug (2 weeks)

--

Comment:

 Fixed URL to haddock docs in description.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2451#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 30 04:45:59 2010
From: trac at galois.com (GHC)
Date: Sat Jan 30 04:17:43 2010
Subject: [GHC] #3848: Error message typo in rts/RtsAPI.c
In-Reply-To: <044.0702ff6eeab4c6d918d0c693dbbdade1@abbot.galois.com>
References: <044.0702ff6eeab4c6d918d0c693dbbdade1@abbot.galois.com>
Message-ID: <053.f5cae7df040b94f1a39115a2406b3154@abbot.galois.com>

#3848: Error message typo in rts/RtsAPI.c
---------------------------------+------------------------------------------
    Reporter:  larsv             |        Owner:  simonmar    
        Type:  bug               |       Status:  assigned    
    Priority:  high              |    Milestone:  6.12.2      
   Component:  Runtime System    |      Version:  6.12.1      
    Keywords:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar
  * priority:  normal => high
  * status:  new => assigned
  * milestone:  => 6.12.2


Comment:

 Thanks, I'll fix that.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3848#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 30 11:37:46 2010
From: trac at galois.com (GHC)
Date: Sat Jan 30 11:09:30 2010
Subject: [GHC] #2797: ghci stack overflows when ghc does not
In-Reply-To: <053.b5bed6c883dfb7d157e5092dcf2242ee@abbot.galois.com>
References: <053.b5bed6c883dfb7d157e5092dcf2242ee@abbot.galois.com>
Message-ID: <062.a9f3c3559ba912a0431147259f7dabaa@abbot.galois.com>

#2797: ghci stack overflows when ghc does not
--------------------------------------+-------------------------------------
  Reporter:  TristanAllwood           |          Owner:  igloo           
      Type:  merge                    |         Status:  closed          
  Priority:  normal                   |      Milestone:  6.12.2          
 Component:  GHCi                     |        Version:  6.11            
Resolution:  fixed                    |       Keywords:                  
Difficulty:  Unknown                  |             Os:  Unknown/Multiple
  Testcase:                           |   Architecture:  Unknown/Multiple
   Failure:  Runtime performance bug  |  
--------------------------------------+-------------------------------------
Changes (by igloo):

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


Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2797#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 30 11:37:59 2010
From: trac at galois.com (GHC)
Date: Sat Jan 30 11:09:43 2010
Subject: [GHC] #2929: INFINITY used in .hc files without -std=c99
In-Reply-To: <045.9c2069ffa5b68c9fb1e9f0987d2d791e@abbot.galois.com>
References: <045.9c2069ffa5b68c9fb1e9f0987d2d791e@abbot.galois.com>
Message-ID: <054.843f003f0e1806f5f50df896620c8410@abbot.galois.com>

#2929: INFINITY used in .hc files without -std=c99
-----------------------------+----------------------------------------------
  Reporter:  duncan          |          Owner:  igloo  
      Type:  merge           |         Status:  closed 
  Priority:  normal          |      Milestone:  6.12.2 
 Component:  Runtime System  |        Version:  6.8.3  
Resolution:  fixed           |       Keywords:         
Difficulty:  Unknown         |             Os:  Solaris
  Testcase:  1861            |   Architecture:  sparc  
   Failure:  None/Unknown    |  
-----------------------------+----------------------------------------------
Changes (by igloo):

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


Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2929#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 30 11:39:15 2010
From: trac at galois.com (GHC)
Date: Sat Jan 30 11:10:58 2010
Subject: [GHC] #3656: ghci leaves /tmp/ghc* directory if killed by signal
In-Reply-To: <042.d95f8802b8c0b09855d12a49e63b7a91@abbot.galois.com>
References: <042.d95f8802b8c0b09855d12a49e63b7a91@abbot.galois.com>
Message-ID: <051.e5fd4b078375c5ce188dc09c6721f2bb@abbot.galois.com>

#3656: ghci leaves /tmp/ghc* directory if killed by signal
---------------------------+------------------------------------------------
  Reporter:  vvv           |          Owner:  igloo           
      Type:  merge         |         Status:  closed          
  Priority:  normal        |      Milestone:  6.12.2          
 Component:  GHCi          |        Version:  6.10.4          
Resolution:  fixed         |       Keywords:                  
Difficulty:                |             Os:  Unknown/Multiple
  Testcase:                |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by igloo):

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


Comment:

 Both merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3656#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 30 11:39:31 2010
From: trac at galois.com (GHC)
Date: Sat Jan 30 11:11:27 2010
Subject: [GHC] #3748: Bug in rts/Win32/Ticker.c can cause process hang
 on exit in Win32
In-Reply-To: <042.ebc1303ba4ba1bb01245ae57d2b8c614@abbot.galois.com>
References: <042.ebc1303ba4ba1bb01245ae57d2b8c614@abbot.galois.com>
Message-ID: <051.aabaa7cb51260334b0d0c61bacf9739f@abbot.galois.com>

#3748: Bug in rts/Win32/Ticker.c can cause process hang on exit in Win32
-----------------------------+----------------------------------------------
  Reporter:  sgf             |          Owner:  igloo           
      Type:  merge           |         Status:  closed          
  Priority:  normal          |      Milestone:  6.12.2          
 Component:  Runtime System  |        Version:  6.10.4          
Resolution:  fixed           |       Keywords:                  
Difficulty:                  |             Os:  Windows         
  Testcase:                  |   Architecture:  Unknown/Multiple
   Failure:  Runtime crash   |  
-----------------------------+----------------------------------------------
Changes (by igloo):

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


Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3748#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 30 12:48:14 2010
From: trac at galois.com (GHC)
Date: Sat Jan 30 12:19:57 2010
Subject: [GHC] #3768: 6.12.1 Mac OS X installer lacks all HTML
 documentation
In-Reply-To: <052.9cb08ea2ad1c2eaf3d32d7297cdfbef7@abbot.galois.com>
References: <052.9cb08ea2ad1c2eaf3d32d7297cdfbef7@abbot.galois.com>
Message-ID: <061.cd889a3550128984f2a5265f4ecc6022@abbot.galois.com>

#3768: 6.12.1 Mac OS X installer lacks all HTML documentation
------------------------------+---------------------------------------------
    Reporter:  Minimiscience  |        Owner:                   
        Type:  bug            |       Status:  new              
    Priority:  normal         |    Milestone:  6.12.2           
   Component:  Documentation  |      Version:  6.12.1           
    Keywords:                 |   Difficulty:                   
          Os:  MacOS X        |     Testcase:                   
Architecture:  x86            |      Failure:  Documentation bug
------------------------------+---------------------------------------------
Changes (by igloo):

  * owner:  igloo =>


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3768#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 30 12:53:50 2010
From: trac at galois.com (GHC)
Date: Sat Jan 30 12:25:33 2010
Subject: [GHC] #3800: sizeofByteArray# returns allocated words,
 not requested length in bytes
In-Reply-To: <052.ddae457e72f5875b2acee6868c0b8060@abbot.galois.com>
References: <052.ddae457e72f5875b2acee6868c0b8060@abbot.galois.com>
Message-ID: <061.a39dd259b1133922bc2156bf6a189cf5@abbot.galois.com>

#3800: sizeofByteArray# returns allocated words, not requested length in bytes
---------------------------------+------------------------------------------
    Reporter:  AntoineLatter     |        Owner:                             
        Type:  bug               |       Status:  new                        
    Priority:  high              |    Milestone:  6.14.1                     
   Component:  Compiler          |      Version:  6.12.1                     
    Keywords:                    |   Difficulty:                             
          Os:  Unknown/Multiple  |     Testcase:                             
Architecture:  Unknown/Multiple  |      Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------
Changes (by igloo):

  * owner:  igloo =>


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3800#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 30 15:46:32 2010
From: trac at galois.com (GHC)
Date: Sat Jan 30 15:18:17 2010
Subject: [GHC] #3833: Panic on standlone deriving without
 GeneralizedNewtypeDeriving
In-Reply-To: <048.153c3186ee473f8a009c1a2b45f3c459@abbot.galois.com>
References: <048.153c3186ee473f8a009c1a2b45f3c459@abbot.galois.com>
Message-ID: <057.cec48a5f96de83db9d9b27df28a9e670@abbot.galois.com>

#3833: Panic on standlone deriving without GeneralizedNewtypeDeriving
---------------------------------+------------------------------------------
  Reporter:  Khudyakov           |          Owner:  igloo           
      Type:  bug                 |         Status:  closed          
  Priority:  normal              |      Milestone:                  
 Component:  Compiler            |        Version:  6.12.1          
Resolution:  fixed               |       Keywords:                  
Difficulty:                      |             Os:  Unknown/Multiple
  Testcase:  T3833               |   Architecture:  Unknown/Multiple
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Changes (by igloo):

  * status:  new => closed
  * testcase:  => T3833
  * resolution:  => fixed


Comment:

 All done

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3833#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 30 15:46:39 2010
From: trac at galois.com (GHC)
Date: Sat Jan 30 15:18:25 2010
Subject: [GHC] #3834: Standalone deriving of an unsupported class panics
 GHC
In-Reply-To: <047.44a3c7a191ed906d7f7ef54a77a3dfad@abbot.galois.com>
References: <047.44a3c7a191ed906d7f7ef54a77a3dfad@abbot.galois.com>
Message-ID: <056.07e05620bdd1a63ab6c8deba71941eba@abbot.galois.com>

#3834: Standalone deriving of an unsupported class panics GHC
---------------------------------+------------------------------------------
  Reporter:  diatchki            |          Owner:                  
      Type:  bug                 |         Status:  closed          
  Priority:  normal              |      Milestone:                  
 Component:  Compiler            |        Version:  6.12.1          
Resolution:  fixed               |       Keywords:                  
Difficulty:                      |             Os:  Unknown/Multiple
  Testcase:  T3834               |   Architecture:  Unknown/Multiple
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Changes (by igloo):

  * status:  new => closed
  * testcase:  => T3834
  * resolution:  => fixed


Comment:

 Fixed

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3834#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 30 15:50:55 2010
From: trac at galois.com (GHC)
Date: Sat Jan 30 15:22:37 2010
Subject: [GHC] #3849: 6.12.1: make framework-pkg on OS X creates package
 with broken installer
Message-ID: <046.4b66a7f2c2a8beb4c5056f2100e3f907@abbot.galois.com>

#3849: 6.12.1: make framework-pkg on OS X creates package with broken installer
---------------------------------+------------------------------------------
    Reporter:  korpios           |       Owner:              
        Type:  bug               |      Status:  new         
    Priority:  normal            |   Component:  Build System
     Version:  6.12.1            |    Keywords:              
          Os:  MacOS X           |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------
 System: OS X 10.6 (Snow Leopard), Intel Core 2 Duo system (64-bit capable,
 running 32-bit kernel), universal (64/32 combined) !MacPorts

 Observed: `.pkg` file built via `make framework-pkg` starts Installer, but
 does not show a dialog box so installation can proceed.

 Expected: Opening the `.pkg` file should have shown a dialog box, same as
 the `.pkg` available from the GHC download page.

 I installed GHC 6.12.1 on OS X via the binary `.pkg`, and then proceeded
 to rebuild it from source via `make framework-pkg` so it would use my
 !MacPorts libraries and not break on libiconv (so I could then install
 xmonad-contrib successfully).  The build process completes and creates a
 file `GHC-6.12.1-i386.pkg`.  When opening this file, Installer launches,
 but nothing else happens ? no dialog opens, etc.  Interestingly, though,
 the contents seem fine; this pkg file can be extracted manually via `xar`,
 and then the package contents therein extracted via `gzip` and `cpio`, and
 the extracted framework directory can then take the place of the existing
 `/Library/Frameworks/GHC.framework` directory and everything works as
 expected (including not breaking on libiconv).

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3849>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 30 17:32:45 2010
From: trac at galois.com (GHC)
Date: Sat Jan 30 17:04:27 2010
Subject: [GHC] #3813: Invalid warning from GHCi
In-Reply-To: <051.207c96ece971d6767ecb4b1e779ba7b2@abbot.galois.com>
References: <051.207c96ece971d6767ecb4b1e779ba7b2@abbot.galois.com>
Message-ID: <060.8ad05d011cfe6a90807d903727fae8ea@abbot.galois.com>

#3813: Invalid warning from GHCi
------------------------------------------------+---------------------------
  Reporter:  NeilMitchell                       |          Owner:  igloo           
      Type:  bug                                |         Status:  closed          
  Priority:  normal                             |      Milestone:  6.12.2          
 Component:  GHCi                               |        Version:  6.10.4          
Resolution:  fixed                              |       Keywords:                  
Difficulty:                                     |             Os:  Unknown/Multiple
  Testcase:                                     |   Architecture:  Unknown/Multiple
   Failure:  Incorrect warning at compile-time  |  
------------------------------------------------+---------------------------
Changes (by igloo):

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


Comment:

 Done, and merged to 6.12.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3813#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 30 19:27:39 2010
From: trac at galois.com (GHC)
Date: Sat Jan 30 18:59:20 2010
Subject: [GHC] #3789: Segfault and -dstg-lint errors using FFI and
 -XEmptyDataDecls
In-Reply-To: <045.2c0f987a4ddd3ec0b9fa039bca72f39b@abbot.galois.com>
References: <045.2c0f987a4ddd3ec0b9fa039bca72f39b@abbot.galois.com>
Message-ID: <054.7595860fbfd2b07aaedff806cc023f69@abbot.galois.com>

#3789: Segfault and -dstg-lint errors using FFI and -XEmptyDataDecls
-------------------------------+--------------------------------------------
    Reporter:  judahj          |        Owner:               
        Type:  bug             |       Status:  new          
    Priority:  high            |    Milestone:  6.12.2       
   Component:  Compiler (NCG)  |      Version:  6.12.1       
    Keywords:                  |   Difficulty:               
          Os:  MacOS X         |     Testcase:               
Architecture:  x86             |      Failure:  Runtime crash
-------------------------------+--------------------------------------------

Comment(by igloo):

 I've merged the "Fix bugs in STG Lint" patch to the 6.12 branch.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3789#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 31 02:05:55 2010
From: trac at galois.com (GHC)
Date: Sun Jan 31 01:37:38 2010
Subject: [GHC] #2451: New signal-handling API
In-Reply-To: <047.5b7641d67bfb4c219c1a85428fd85097@abbot.galois.com>
References: <047.5b7641d67bfb4c219c1a85428fd85097@abbot.galois.com>
Message-ID: <056.188d770a1d3e6fd9420e5e7fbf6e5524@abbot.galois.com>

#2451: New signal-handling API
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  simonmar    
        Type:  proposal          |       Status:  new         
    Priority:  high              |    Milestone:  6.14 branch 
   Component:  libraries/unix    |      Version:  6.8.3       
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by bos):

 * cc: bos@? (added)


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2451#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 31 02:14:33 2010
From: trac at galois.com (GHC)
Date: Sun Jan 31 01:46:14 2010
Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT
In-Reply-To: <045.f06a53427920f75d02000e2372e27573@abbot.galois.com>
References: <045.f06a53427920f75d02000e2372e27573@abbot.galois.com>
Message-ID: <054.bad56f13261044ea1a20d0c90e9055ee@abbot.galois.com>

#2301: Proper handling of SIGINT/SIGQUIT
---------------------------+------------------------------------------------
  Reporter:  duncan        |           Type:  bug              
    Status:  new           |       Priority:  normal           
 Milestone:  6.14.1        |      Component:  libraries/process
   Version:  6.8.2         |       Keywords:                   
Difficulty:  Unknown       |             Os:  Unknown/Multiple 
  Testcase:                |   Architecture:  Unknown/Multiple 
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by bos):

 * cc: bos@? (added)


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2301#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 31 10:11:56 2010
From: trac at galois.com (GHC)
Date: Sun Jan 31 09:43:41 2010
Subject: [GHC] #2451: New signal-handling API
In-Reply-To: <047.5b7641d67bfb4c219c1a85428fd85097@abbot.galois.com>
References: <047.5b7641d67bfb4c219c1a85428fd85097@abbot.galois.com>
Message-ID: <056.d26b06ba4aa98dfdf10b183124786f3c@abbot.galois.com>

#2451: New signal-handling API
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  simonmar    
        Type:  proposal          |       Status:  new         
    Priority:  high              |    Milestone:  6.14 branch 
   Component:  libraries/unix    |      Version:  6.8.3       
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by tibbe):

 * cc: tibbe (added)


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2451#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 31 10:12:29 2010
From: trac at galois.com (GHC)
Date: Sun Jan 31 09:44:08 2010
Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT
In-Reply-To: <045.f06a53427920f75d02000e2372e27573@abbot.galois.com>
References: <045.f06a53427920f75d02000e2372e27573@abbot.galois.com>
Message-ID: <054.d41c5e12ddb2ac4dcd7310867af94b20@abbot.galois.com>

#2301: Proper handling of SIGINT/SIGQUIT
---------------------------+------------------------------------------------
  Reporter:  duncan        |           Type:  bug              
    Status:  new           |       Priority:  normal           
 Milestone:  6.14.1        |      Component:  libraries/process
   Version:  6.8.2         |       Keywords:                   
Difficulty:  Unknown       |             Os:  Unknown/Multiple 
  Testcase:                |   Architecture:  Unknown/Multiple 
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by tibbe):

 * cc: tibbe (added)


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2301#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 31 18:18:12 2010
From: trac at galois.com (GHC)
Date: Sun Jan 31 17:50:05 2010
Subject: [GHC] #3850: EmptyDataDecls and type context
Message-ID: <049.f27f0f58200e17d4e5b9ff32a4c6b128@abbot.galois.com>

#3850: EmptyDataDecls and type context
---------------------------------+------------------------------------------
    Reporter:  Paczesiowa        |       Owner:                           
        Type:  bug               |      Status:  new                      
    Priority:  normal            |   Component:  Compiler                 
     Version:  6.12.1            |    Keywords:  emptydatadecls           
          Os:  Unknown/Multiple  |    Testcase:                           
Architecture:  Unknown/Multiple  |     Failure:  GHC rejects valid program
---------------------------------+------------------------------------------
 the following code fails to parse correctly or typecheck under 6.12.1


 {{{
 {-# LANGUAGE EmptyDataDecls #-}
 data Show a => Foo a
 }}}


 error:


 {{{
     No context is allowed on a GADT-style data declaration
     (You can put a context on each contructor, though.)
 }}}


 it works with 6.10.

 this is the reason of HList failure on 6.12.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3850>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler