Re: [GHC] #2671: Data.Time.Clock parseTime's %y parses "08" as 1908

[GHC]

#2671: Data.Time.Clock parseTime's %y parses "08" as 1908
--+-
Reporter:  simonmic   |Owner:  ashley@…   
Type:  bug|   Status:  merge  
Priority:  normal |Milestone:  7.2.1  
   Component:  libraries (other)  |  Version:  6.8.2  
Keywords:  time   | Testcase: 
   Blockedby: |   Difficulty:  Unknown
  Os:  Unknown/Multiple   | Blocking: 
Architecture:  Unknown/Multiple   |  Failure:  None/Unknown   
--+-
Changes (by Ashley Yakeley):

  * status:  new => merge


Comment:

 Fixed in time-1.2.0.5.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

[GHC] #5191: panic! (the 'impossible' happened) - thread blocked indefinitely in an MVar operation

[GHC]

#5191: panic! (the 'impossible' happened) - thread blocked indefinitely in an 
MVar
operation
+---
Reporter:  guest|   Owner:
Type:  bug  |  Status:  new   
Priority:  normal   |   Component:  GHCi  
 Version:  7.0.3|Keywords:
Testcase:   |   Blockedby:
  Os:  Windows  |Blocking:
Architecture:  x86  | Failure:  GHCi crash
+---
 I was trying to get out of GHCi anyway, but I got it to crash by doing the
 following:

 Type ^c (control+c)
 Type at least two other characters (e.g. 'ab')
 (The first character is not echoed back)
 Press  key

 Result:
 :1:1: Not in scope: `b'
 Prelude>
 ghc.exe: panic! (the 'impossible' happened)
   (GHC version 7.0.3 for i386-unknown-mingw32):
 thread blocked indefinitely in an MVar operation

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5004: loading stripped libHsghc-7.0.2.a fails

[GHC]

#5004: loading stripped libHsghc-7.0.2.a fails
-+--
Reporter:  pbrisbin  |Owner:  duncan
Type:  bug   |   Status:  new   
Priority:  highest   |Milestone:  7.2.1 
   Component:  Compiler  |  Version:  7.0.2 
Keywords:| Testcase:
   Blockedby:|   Difficulty:
  Os:  Linux | Blocking:
Architecture:  Unknown/Multiple  |  Failure:  GHCi crash
-+--

Comment(by duncan):

 Replying to [comment:17 twhitehead]:
 > Just finished running into this on Debian.  Looks like the problem is
 that the ''keepCAFsForGHCi.o'' object file in the archive has no symbols
 but debug ones.

 Thanks, this turns out to be the core issue. It's fortunately nothing to
 do with debug symbols or jump islands.

 So when linking we definitely need a symbol table and its corresponding
 string table. Using `strip` on a `.o` or `.a` file will remove both
 tables. In this situation neither the system linker nor the GHCi linker
 cannot do anything with it.

 Linux distros of course do not use just `strip`, they typically use `strip
 --strip-unneeded`. The `strip --strip-unneeded` command does not remove
 symbol tables, it just filters out the symbols not needed for relocation
 processing.

 There is one important exception to the above however: `strip --strip-
 unneeded` '''does''' remove the symbol table when the symbol table is
 empty (after the usual filtering).

 That is exactly what is happening with `keepCAFsForGHCi.o`. The
 `keepCAFsForGHCi.c` has just one function, and it is conditionally
 compiled so that it only appears only in the dynamic way. So
 `keepCAFsForGHCi.dyn_o` has the function in it, while the ordinary
 `keepCAFsForGHCi.o` is basically an empty object file. So when we `strip
 --strip-unneeded` on the `libHSghc.a` then the archive member
 `keepCAFsForGHCi.o` ends up with no symbol table.

 So, the solution is probably to recognise when an object file exports no
 symbols and has no relocations requiring symbols. Thus for these object
 files we do not need their symbol table at all. So it should be just a
 matter of adjusting the order in which various things are validated and
 checked.

 It is interesting to note that the system linker does not complain about
 object files with no symbol table, it just fails when it cannot find the
 target symbols that it needs. So it apparently just treats lack of a
 symbol table as no symbols. Perhaps we can do the same.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

[GHC] #5190: TinyCoreLinux extension

[GHC]

#5190: TinyCoreLinux extension
-+--
Reporter:  josemaria.alkala  |   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Component:  Build System   
 Version:  7.0.3 |Keywords: 
Testcase:|   Blockedby: 
  Os:  Linux |Blocking: 
Architecture:  x86   | Failure:  Building GHC failed
-+--
 I am trying to create a GHC package for TinyCoreLinux
 http://www.tinycorelinux.com (this is a 10Mbytes linux distribution)

 I have downloaded the general binary:
 http://haskell.org/ghc/dist/7.0.3/ghc-7.0.3-i386-unknown-linux.tar.bz2

 When I execute: ./configure, I get:
 checking for path to top of build tree... ghc-pwd: mkTextEncoding: invalid
 argument (Invalid argument)
 configure: error: cannot determine current directory

 As a disclaimer, I am not a developer!

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #3304: define gcd 0 0 = 0

[GHC]

#3304: define gcd 0 0 = 0
-+--
  Reporter:  stevec  |  Owner:  
  Type:  proposal| Status:  new 
  Priority:  normal  |  Milestone:  7.2.1   
 Component:  libraries/base  |Version:  6.10.3  
Resolution:  |   Keywords:  
  Testcase:  |  Blockedby:  
Difficulty:  Unknown | Os:  Unknown/Multiple
  Blocking:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--
Changes (by asr):

 * cc: andres.sicard.ramirez@… (added)


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

[GHC] #5189: incorrect pragma syntax leeds to panic

[GHC]

#5189: incorrect pragma syntax leeds to panic
--+-
Reporter:  zickzackv  |   Owner:  
Type:  bug|  Status:  new 
Priority:  normal |   Component:  Compiler
 Version:  6.10.4 |Keywords:  pragma panic
Testcase: |   Blockedby:  
  Os:  MacOS X|Blocking:  
Architecture:  x86| Failure:  GHCi crash  
--+-
 When using a wrong pragma syntax  like:

 {-# LANGUAGE IncoherentInstances -#}
 {-# LANGUAGE OverlappingInstances #-} -- wrong pragma syntax!
 {-# LANGUAGE NoMonomorphismRestriction #-}
 {-# LANGUAGE MultiParamTypeClasses #-}

 This leeds to the following ghc panic:

 ghc: panic! (the 'impossible' happened)
   (GHC version 6.10.4 for x86_64-apple-darwin):
 getOptions'.parseLanguage(1) went past eof token

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

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

[GHC] #5188: Runtime error when allocating lots of memory

[GHC]

#5188: Runtime error when allocating lots of memory
+---
Reporter:  knyblad  |   Owner:  
Type:  bug  |  Status:  new 
Priority:  normal   |   Component:  GHCi
 Version:  6.12.1   |Keywords:  
Testcase:   |   Blockedby:  
  Os:  Linux|Blocking:  
Architecture:  x86  | Failure:  None/Unknown
+---
 In GHCI execute

 let powers = 2:map (2^) powers
 powers

 When calculating the fourth element of the list, you get the following
 error message:

 : internal error: getMBlock: mmap: Invalid argument
 (GHC version 6.12.1 for i386_unknown_linux)
 Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug

 If you have trouble reproducing the bug, try substituting an other number
 for 2 in the code, e.g. I have also got that error message when I defined
 powers as:

 let powers = 4:map (4^) powers

 and

 let powers = 13:map (13^) powers

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

[GHC] #5187: missing deRefTSO in scheduleHandleThreadFinished

[GHC]

#5187: missing deRefTSO in scheduleHandleThreadFinished
-+--
Reporter:  simonmar  |Owner:   
Type:  bug   |   Status:  new  
Priority:  highest   |Milestone:  7.0.4
   Component:  Runtime System|  Version:  6.12.3   
Keywords:| Testcase:   
   Blockedby:|   Difficulty:   
  Os:  Unknown/Multiple  | Blocking:   
Architecture:  Unknown/Multiple  |  Failure:  Runtime crash
-+--
 Duncan Coutts reported this one.  ThreadScope was crashing, we think
 because in `scheduleHandleThreadFinished` there ought to be a call to
 `deRefTSO` before

 {{{
   ASSERT(task->incall->tso == t);
 }}}

 (the value of `task->incall->tso is used for real a bit further down).

 This only applies to the 7.0 branch, `deRefTSO` has gone in 7.2 and later.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5178: RULES "minusFloat x x" and "timesFloat 0.0 x" break IEEE-754 compatibility

[GHC]

#5178: RULES "minusFloat x x" and "timesFloat 0.0 x" break IEEE-754 
compatibility
--+-
  Reporter:  liyang   |  Owner:  simonmar
  Type:  bug  | Status:  closed  
  Priority:  high |  Milestone:  7.2.1   
 Component:  libraries/base   |Version:  7.0.3   
Resolution:  fixed|   Keywords:  
  Testcase:   |  Blockedby:  
Difficulty:   | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  Incorrect result at runtime  |  
--+-
Changes (by simonmar):

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


Comment:

 Done: changeset:b751723d882e51241f04d6d2ec46fce70f0e0817

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5184: createDirectory does not retry on EINTR (interrupted)

[GHC]

#5184: createDirectory does not retry on EINTR (interrupted)
--+-
  Reporter:  CoreyOConnor |  Owner:  simonmar
  Type:  bug  | Status:  closed  
  Priority:  high |  Milestone:  7.2.1   
 Component:  libraries/unix   |Version:  7.0.3   
Resolution:  fixed|   Keywords:  
  Testcase:   |  Blockedby:  
Difficulty:   | Os:  MacOS X 
  Blocking:   |   Architecture:  x86 
   Failure:  Incorrect result at runtime  |  
--+-
Changes (by simonmar):

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


Comment:

 Done: changeset:b7b180d23472dca03fb4c809cd86bcd6d3f01ea9

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #3304: define gcd 0 0 = 0

[GHC]

#3304: define gcd 0 0 = 0
-+--
  Reporter:  stevec  |  Owner:  
  Type:  proposal| Status:  new 
  Priority:  normal  |  Milestone:  7.2.1   
 Component:  libraries/base  |Version:  6.10.3  
Resolution:  |   Keywords:  
  Testcase:  |  Blockedby:  
Difficulty:  Unknown | Os:  Unknown/Multiple
  Blocking:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--

Comment(by YitzGale):

 Replying to [comment:5 simonmar]:
 > So we need to change `gcd` in `GHC.Real`, but also
 > reinstate the old behaviour for the `haskell98` and
 > `haskell2010` packages, correct?

 I suppose that would be the squeaky-clean way of doing
 things, especially since the documentation explicitly
 mentions the old behavior of calling `error`.

 But most people view this as a bug fix. It seems highly
 unlikely that anyone would really want the old behavior
 for anything.

 Personally, I would be happy either way, as long as it
 finally gets fixed.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5002: 7.0.2 ignores a context which 7.0.1 picks up

[GHC]

#5002: 7.0.2 ignores a context which 7.0.1 picks up
+---
Reporter:  patrick_premont  |Owner:  simonpj  
Type:  bug  |   Status:  new  
Priority:  highest  |Milestone:  7.2.1
   Component:  Compiler |  Version:  7.0.2
Keywords:   | Testcase:   
   Blockedby:   |   Difficulty:   
  Os:  Windows  | Blocking:   
Architecture:  x86  |  Failure:  GHC rejects valid program
+---

Comment(by dimitris):

 OK yes this is indeed related to #4981 and is fixed because of saturation
 of equalities, but there's more work to be done -- see the commentary on
 #4981. I will
 add both these to the testsuite.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #4981: inconsistent class requirements with TypeFamilies and FlexibleContexts

[GHC]

#4981: inconsistent class requirements with TypeFamilies and FlexibleContexts
+---
Reporter:  ganesh   |Owner:  simonpj
  
Type:  bug  |   Status:  new
  
Priority:  high |Milestone:  7.2.1  
  
   Component:  Compiler (Type checker)  |  Version:  7.0.1  
  
Keywords:   | Testcase: 
  
   Blockedby:   |   Difficulty: 
  
  Os:  Unknown/Multiple | Blocking: 
  
Architecture:  Unknown/Multiple |  Failure:  GHC rejects valid 
program
+---

Comment(by dimitris):

 OK I agree with Simon but the saturation of equalities is independently
 useful and
 I have already implemented it and pushed, so this example works now. I
 will add it to the testsuite and start implementing Simon's proposal.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5180: dry run option -n broken

[GHC]

#5180: dry run option -n broken
---+
Reporter:  hammar  |Owner:  simonmar  
Type:  bug |   Status:  new   
Priority:  normal  |Milestone:
   Component:  Compiler|  Version:  7.0.2 
Keywords:  | Testcase:
   Blockedby:  |   Difficulty:
  Os:  Linux   | Blocking:
Architecture:  x86_64 (amd64)  |  Failure:  Compile-time crash
---+
Changes (by simonmar):

  * owner:  => simonmar


Comment:

 Does anyone actually need this flag?  It looks to be non-trivial to make
 it work.  In fact, I'm not at all clear what it should do.  It can't
 really do anything sensible in conjunction with `--make`, because in order
 to do the dependency analysis you have to run preprocessors on the source
 files, and `-n` doesn't let you run the preprocessors.

 I propose to get rid of the flag.  Any objections?

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #3304: define gcd 0 0 = 0

[GHC]

#3304: define gcd 0 0 = 0
-+--
  Reporter:  stevec  |  Owner:  
  Type:  proposal| Status:  new 
  Priority:  normal  |  Milestone:  7.2.1   
 Component:  libraries/base  |Version:  6.10.3  
Resolution:  |   Keywords:  
  Testcase:  |  Blockedby:  
Difficulty:  Unknown | Os:  Unknown/Multiple
  Blocking:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--
Changes (by simonmar):

  * milestone:  Not GHC => 7.2.1


Comment:

 So we need to change `gcd` in `GHC.Real`, but also reinstate the old
 behaviour for the `haskell98` and `haskell2010` packages, correct?

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5184: createDirectory does not retry on EINTR (interrupted)

[GHC]

#5184: createDirectory does not retry on EINTR (interrupted)
---+
Reporter:  CoreyOConnor|Owner:  simonmar   
Type:  bug |   Status:  new
Priority:  high|Milestone:  7.2.1  
   Component:  libraries/unix  |  Version:  7.0.3  
Keywords:  | Testcase: 
   Blockedby:  |   Difficulty: 
  Os:  MacOS X | Blocking: 
Architecture:  x86 |  Failure:  Incorrect result at runtime
---+
Changes (by simonmar):

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


Comment:

 The POSIX spec doesn't say that `mkdir` can return `EINTR`, so I suppose
 OS X is non-standard here.  I'll fix it in `System.Posix.Directory`
 anyway.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5178: RULES "minusFloat x x" and "timesFloat 0.0 x" break IEEE-754 compatibility

[GHC]

#5178: RULES "minusFloat x x" and "timesFloat 0.0 x" break IEEE-754 
compatibility
-+--
Reporter:  liyang|Owner:  simonmar   
Type:  bug   |   Status:  new
Priority:  high  |Milestone:  7.2.1  
   Component:  libraries/base|  Version:  7.0.3  
Keywords:| Testcase: 
   Blockedby:|   Difficulty: 
  Os:  Unknown/Multiple  | Blocking: 
Architecture:  Unknown/Multiple  |  Failure:  Incorrect result at runtime
-+--
Changes (by simonmar):

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


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #2715: Equality constraint in superclass not supported

[GHC]

#2715: Equality constraint in superclass not supported
+---
Reporter:  rodprice |Owner:  chak
Type:  task |   Status:  new 
Priority:  low  |Milestone:  7.2.1   
   Component:  Compiler (Type checker)  |  Version:  6.10.1  
Keywords:   | Testcase:  
   Blockedby:   |   Difficulty:  Unknown 
  Os:  Linux| Blocking:  
Architecture:  x86  |  Failure:  None/Unknown
+---
Changes (by baramoglo):

 * cc: 78emil@… (added)


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #3304: define gcd 0 0 = 0

[GHC]

#3304: define gcd 0 0 = 0
-+--
  Reporter:  stevec  |  Owner:  
  Type:  proposal| Status:  new 
  Priority:  normal  |  Milestone:  Not GHC 
 Component:  libraries/base  |Version:  6.10.3  
Resolution:  |   Keywords:  
  Testcase:  |  Blockedby:  
Difficulty:  Unknown | Os:  Unknown/Multiple
  Blocking:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--
Changes (by YitzGale):

 * cc: gale@… (added)
  * status:  closed => new
  * resolution:  wontfix =>


Comment:

 Replying to [comment:3 igloo]:
 > Looks like an abandoned proposal

 No, it just keeps getting mired in Library Proposal red tape.

 It came up yet again, this time proposed by Daniel Fischer with
 comprehensive justification:

 http://www.haskell.org/pipermail/haskell-prime/2011-May/003403.html

 Every time, it gets universal enthusiastic support, then dies on
 procedure.
 Could you please just apply it?
 CC the haskell-prime list so that they'll apply it there, too.

 Thanks!

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5070: dph and new code generator don't play nicely with each other

[GHC]

#5070: dph and new code generator don't play nicely with each other
--+-
Reporter:  ezyang |Owner:  benl 
  
Type:  bug|   Status:  new  
  
Priority:  normal |Milestone:  7.2.1
  
   Component:  Data Parallel Haskell  |  Version:  7.0.3
  
Keywords: | Testcase:   
  
   Blockedby:  5065   |   Difficulty:   
  
  Os:  Unknown/Multiple   | Blocking:   
  
Architecture:  Unknown/Multiple   |  Failure:  Incorrect result at 
runtime
--+-
Changes (by simonpj):

  * owner:  => benl


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5179: Unexpected Failure due to change of defaultDynFlags' type

[GHC]

#5179: Unexpected Failure due to change of defaultDynFlags' type
--+-
Reporter:  daniel.is.fischer  |Owner:  igloo
Type:  bug|   Status:  new  
Priority:  high   |Milestone:  7.2.1
   Component:  Test Suite |  Version:  7.1  
Keywords: | Testcase:   
   Blockedby: |   Difficulty:   
  Os:  Unknown/Multiple   | Blocking:   
Architecture:  Unknown/Multiple   |  Failure:  Other
--+-
Changes (by simonpj):

  * milestone:  => 7.2.1


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5179: Unexpected Failure due to change of defaultDynFlags' type

[GHC]

#5179: Unexpected Failure due to change of defaultDynFlags' type
--+-
Reporter:  daniel.is.fischer  |Owner:  igloo
Type:  bug|   Status:  new  
Priority:  high   |Milestone:   
   Component:  Test Suite |  Version:  7.1  
Keywords: | Testcase:   
   Blockedby: |   Difficulty:   
  Os:  Unknown/Multiple   | Blocking:   
Architecture:  Unknown/Multiple   |  Failure:  Other
--+-
Changes (by simonpj):

  * owner:  => igloo
  * priority:  normal => high


Comment:

 Ian is taking this.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5182: spec001 now wants StandaloneDeriving

[GHC]

#5182: spec001 now wants StandaloneDeriving
+---
  Reporter:  daniel.is.fischer  |  Owner:  
  Type:  bug| Status:  closed  
  Priority:  normal |  Milestone:  
 Component:  Test Suite |Version:  7.1 
Resolution:  fixed  |   Keywords:  
  Testcase: |  Blockedby:  
Difficulty: | Os:  Unknown/Multiple
  Blocking: |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown   |  
+---
Changes (by simonpj):

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


Comment:

 Ah yes, I was in too much of a hurry last night. Fixed, thanks.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5181: HEAD panics on mc17

[GHC]

#5181: HEAD panics on mc17
+---
  Reporter:  daniel.is.fischer  |  Owner:  
  Type:  bug| Status:  closed  
  Priority:  normal |  Milestone:  
 Component:  Compiler   |Version:  7.1 
Resolution:  fixed  |   Keywords:  
  Testcase: |  Blockedby:  
Difficulty: | Os:  Unknown/Multiple
  Blocking: |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown   |  
+---
Changes (by simonpj):

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


Comment:

 Fixed by
 {{{
 commit 6a1aab7737016aa714b2ffec2b5657a18fac0e42
 Author: Simon Peyton Jones 
 Date:   Mon May 9 16:45:12 2011 +0100

 Fix renaming of guards

 This was making mc17 fail.

 >---

  compiler/hsSyn/HsExpr.lhs  |   10 ++
  compiler/rename/RnExpr.lhs |2 ++
  2 files changed, 8 insertions(+), 4 deletions(-)

 diff --git a/compiler/hsSyn/HsExpr.lhs b/compiler/hsSyn/HsExpr.lhs index
 9c88783..dd33cae 100644
 --- a/compiler/hsSyn/HsExpr.lhs
 +++ b/compiler/hsSyn/HsExpr.lhs
 @@ -1274,10 +1274,12 @@ data HsStmtContext id  \begin{code}
 isListCompExpr :: HsStmtContext id -> Bool
  -- Uses syntax [ e | quals ]
 -isListCompExpr ListComp  = True
 -isListCompExpr PArrComp  = True
 -isListCompExpr MonadComp = True
 -isListCompExpr _ = False
 +isListCompExpr ListComp = True
 +isListCompExpr PArrComp = True
 +isListCompExpr MonadComp= True
 +isListCompExpr (ParStmtCtxt c)   = isListCompExpr c
 +isListCompExpr (TransStmtCtxt c) = isListCompExpr c
 +isListCompExpr _ = False

  isMonadCompExpr :: HsStmtContext id -> Bool
  isMonadCompExpr MonadComp= True
 diff --git a/compiler/rename/RnExpr.lhs b/compiler/rename/RnExpr.lhs index
 46eef67..88e0462 100644
 --- a/compiler/rename/RnExpr.lhs
 +++ b/compiler/rename/RnExpr.lhs
 @@ -694,6 +694,8 @@ rnStmt ctxt (L loc (ExprStmt expr _ _ _)) thing_inside
then lookupStmtName ctxt guardMName
   else return (noSyntaxExpr, emptyFVs)
   -- Only list/parr/monad comprehensions use
 'guard'
 + -- Also for sub-stmts of same eg [ e |
 x<-xs, gd | blah ]
 + -- Here "gd" is a guard
 ; (thing, fvs3)<- thing_inside []
 ; return (([L loc (ExprStmt expr' then_op guard_op
 placeHolderType)], thing),
   fv_expr `plusFV` fvs1 `plusFV` fvs2 `plusFV` fvs3) }
 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5183: HEAD: panic addTickHsCmd for T3822

[GHC]

#5183: HEAD: panic addTickHsCmd for T3822
+---
  Reporter:  daniel.is.fischer  |  Owner:  simonpj 
  Type:  bug| Status:  closed  
  Priority:  normal |  Milestone:  
 Component:  Compiler   |Version:  7.1 
Resolution:  fixed  |   Keywords:  
  Testcase: |  Blockedby:  
Difficulty: | Os:  Unknown/Multiple
  Blocking: |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown   |  
+---
Changes (by simonpj):

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


Comment:

 Fixed by
 {{{
 commit 13f959e89c4a23cb2337fb3157f3d7a679debf99
 Author: Simon Peyton Jones 
 Date:   Mon May 9 16:44:30 2011 +0100

 Fix the desugaring of guards in arrow syntax

 This was making T3822 fail, which it has apparently been doing
 for some time (ie in GHC 7, 6.12, 6.10)!

 >---

  compiler/deSugar/Coverage.lhs |9 ++---
  1 files changed, 6 insertions(+), 3 deletions(-)

 diff --git a/compiler/deSugar/Coverage.lhs b/compiler/deSugar/Coverage.lhs
 index 8071da7..37cbc2d 100644
 --- a/compiler/deSugar/Coverage.lhs
 +++ b/compiler/deSugar/Coverage.lhs
 @@ -608,9 +608,12 @@ addTickCmdGRHSs (GRHSs guarded local_binds) = do
  binders = collectLocalBinders local_binds

  addTickCmdGRHS :: GRHS Id -> TM (GRHS Id) -addTickCmdGRHS (GRHS stmts
 cmd) = do
 -  (stmts',expr') <- addTickLCmdStmts' stmts (addTickLHsCmd cmd)
 -  return $ GRHS stmts' expr'
 +-- The *guards* are *not* Cmds, although the body is
 +-- C.f. addTickGRHS for the BinBox stuff addTickCmdGRHS (GRHS stmts
 +cmd)
 +  = do { (stmts',expr') <- addTickLStmts' (Just $ BinBox $ GuardBinBox)
 +   stmts (addTickLHsCmd cmd)
 +   ; return $ GRHS stmts' expr' }

  addTickLCmdStmts :: [LStmt Id] -> TM [LStmt Id]  addTickLCmdStmts stmts =
 do
 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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