Re: [GHC] #1781: Type equality class leads to non-termination
#1781: Type equality class leads to non-termination
+---
Reporter: chak |Owner:
Type: bug | Status: new
Priority: normal |Milestone:
Component: Compiler (Type checker) | Version: 6.9
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Os: Unknown | Testcase:
Architecture: Unknown |
+---
Changes (by chak):
* severity: blocker = normal
Comment:
Replying to [comment:2 guest]:
I set the milestone to 6.8.1 and the severity to blocker, and I hope for
your understanding. The reason is that at the moment it seems to be
impossible to implement a HList-like equality test. At some point you
need a type equality constraint, either {{{t1 ~ t2}}} or {{{E t1 t2}}}
(with {{{E}}} being defined as above). But neither of them works! The
latter doesn’t work because of this very bug, the former doesn’t work
probably because of bug #1754. So if GHC 6.8.1 is released without this
bug being fixed I’ll probably have to tell my users (of Grapefruit) that
they need something like GHC 6.8.0.20070916. :-(
You may have misunderstood the problem exposed by this bug - maybe my
explanation just wasn't clear. The problem is '''not''' with the
equality class `E` as such. It's with this particular use in the
definition of `plus`, where the signature type contains a type variable
that is constrained to be a function by the class context. This is
something that has '''never''' worked in GHC, so I doubt that it breaks
any existing code.
Having said that, maybe you found some other problems with `E`. Then,
please document them in a separate bug (if you haven't yet). In any case,
this particular bug is surely no blocker, in fact it is fairly obscure and
I'd doubt anybody is going to run into it.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1781#comment:5
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
[GHC] #1793: Compiling QuickCheck fails
#1793: Compiling QuickCheck fails
+---
Reporter: guest | Owner:
Type: bug| Status: new
Priority: normal | Milestone:
Component: libraries (other) |Version: 6.9
Severity: normal | Keywords:
Difficulty: Unknown| Os: Unknown
Testcase: | Architecture: Unknown
+---
I did a 'darcs get' on 2007-10-19, ran boot and configure and then tried
'make'.
{{{
c:/LA/ghc-HEAD/compiler/stage1/ghc-inplace.exe -M -optdep-f
-optdepdist/build/.depend -optdep-s -optdepp -package-name
QuickCheck-1.0.1 -hide-all-packages -i -idist/build/autogen -idist/build
-i. -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build
-package base-2.1 -O -XCPP -idist/build -H32m -O2 Debug.QuickCheck.Batch
Debug.QuickCheck.Poly Debug.QuickCheck.Utils Debug.QuickCheck
Test.QuickCheck.Batch Test.QuickCheck.Poly Test.QuickCheck.Utils
Test.QuickCheck
Test/QuickCheck/Batch.hs:93:7:
Could not find module `System.Random':
it is a member of package random-1.0, which is hidden
make[2]: *** [dist/build/.depend] Error 1
make[2]: Leaving directory `/c/LA/ghc-HEAD/libraries/QuickCheck'
make[1]: *** [make.library.QuickCheck] Error 2
make[1]: Leaving directory `/c/LA/ghc-HEAD/libraries'
make: *** [stage1] Error 2
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1793
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
Re: [GHC] #1793: Compiling QuickCheck fails
#1793: Compiling QuickCheck fails --+- Reporter: guest |Owner: Type: bug| Status: closed Priority: normal |Milestone: Component: libraries (other) | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Os: Unknown| Testcase: Architecture: Unknown| --+- Changes (by duncan): * status: new = closed * resolution: = duplicate Comment: Same problem as bug #1790, that ghc-HEAD's base version needs fixing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1793#comment:1 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
Re: [GHC] #1372: Recompilation checker should consider package versions (and other factors)
#1372: Recompilation checker should consider package versions (and other factors) -+-- Reporter: bringert |Owner: simonmar Type: bug | Status: new Priority: normal|Milestone: 6.8 branch Component: Compiler | Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Comment (by simonmar): Replying to [comment:10 dons]: I'd like to understand what happened a bit better, because I think there are actually several different issues. Correct me if I'm wrong, but the error in the thread you referred to was caused by: * X11-extras was updated, the API was changed, the version was not bumped * xmonad was updated to match * it failed to compile against the old X11-extras that's expected, right? And there seems to be some problem with Cabal not noticing when a .hsc file has been modified, that sounds like a Cabal bug. The problem you described seems slightly different: * X11-extras is modified, the version is bumped * xmonad is updated to match (with a dependency on the new version) * `darcs pull xmonad` * without cleaning first, `setup build` Now, Cabal doesn't notice that `xmonad.cabal` has been updated, and hence doesn't notice that it needs to depend on the new version of X11-extras. If this is the case, it's a Cabal bug - Cabal should refuse to build if the `.cabal` file has been modified since the last configure. I've been thinking about how to solve the original recompilation problem. I even hacked up the fix proposed earlier, but then decided it was wrong. We can't rely on packages being registered to notice when things change - the compiler really needs to look at the `.hi` files. Ideally, we need to create a fingerprint of the interface (hence SimonPJs message to the Haskell mailing list about fingerprints). None of this will help unless Cabal invokes GHC to do recompilation checking: so if Cabal starts doing its own dependency analysis, we'll be in trouble again. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1372#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
Re: [GHC] #1785: xargs failure
#1785: xargs failure
-+--
Reporter: guest |Owner: simonmar
Type: bug | Status: closed
Priority: normal|Milestone: 6.8.1
Component: Compiler | Version: 6.8
Severity: normal| Resolution: fixed
Keywords:| Difficulty: Unknown
Os: Solaris | Testcase:
Architecture: x86 |
-+--
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
I removed the use of the -s option:
{{{
Thu Oct 18 07:05:00 PDT 2007 Simon Marlow [EMAIL PROTECTED]
* FIX GHC bug #1785: use 2048 as the maximum command-line size
Fri Oct 19 05:45:22 PDT 2007 Simon Marlow [EMAIL PROTECTED]
* refinement of fix for #1785: don't use xargs' -s option at all
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1785#comment:5
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
[GHC] #1794: map has strange unfolding, code blowup and performance loss
#1794: map has strange unfolding, code blowup and performance loss
---+
Reporter: simonmar | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 6.8.1
Component: Compiler |Version: 6.6.1
Severity: normal| Keywords:
Difficulty: Moderate (1 day) | Os: Unknown
Testcase:| Architecture: Unknown
---+
{{{
module Test where
f xs = map (True:) xs
}}}
gives this with ghc-6.8.1 -O -ddump-simpl:
{{{
Tidy Core
Rec {
Test.go :: [[GHC.Base.Bool]] - [[GHC.Base.Bool]]
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType S]
Test.go =
\ (ds_a6S :: [[GHC.Base.Bool]]) -
case ds_a6S of wild_a6T {
[] - GHC.Base.[] @ [GHC.Base.Bool];
: y_a6X ys_a6Y -
GHC.Base.:
@ [GHC.Base.Bool]
(GHC.Base.: @ GHC.Base.Bool GHC.Base.True y_a6X)
(Test.go ys_a6Y)
}
end Rec }
Test.f :: [[GHC.Base.Bool]] - [[GHC.Base.Bool]]
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType S]
Test.f =
\ (xs_a5B :: [[GHC.Base.Bool]]) -
case xs_a5B of wild_a5Q {
[] - GHC.Base.[] @ [GHC.Base.Bool];
: x_a5T xs1_a5U -
GHC.Base.:
@ [GHC.Base.Bool]
(GHC.Base.: @ GHC.Base.Bool GHC.Base.True x_a5T)
(Test.go xs1_a5U)
}
}}}
This is not, as I first suspected, that the `mapList` rule is not firing -
the RULEs are firing as they should. The problem is that `map` itself has
this unfolding:
{{{
map :: forall a b. (a - b) - [a] - [b]
{- Arity: 2 HasNoCafRefs Strictness: LS
Unfolding: (\ @ a @ b ds :: a - b ds1 :: [a] -
case @ [b] ds1 of wild {
[] - GHC.Base.[] @ b
: x xs
- GHC.Base.:
@ b
(ds x)
(GHC.Base.foldr
@ a
@ [b]
(\ x1 :: a ys :: [b] - GHC.Base.: @ b (ds x1)
ys)
(GHC.Base.[] @ b)
xs) }) -}
}}}
Highly strange - `map`'s unfolding refers to `foldr`, but `map` itself is
written with the usual recursive definition in `GHC.Base`. The only
explanation I can think of is that the RULEs for `map` must have applied
in `map`'s definition when `GHC.Base` was compiled.
This is bad, because of the code blowup and also because performance will
be badly affected for non-optimised compilation (`map` is defined in terms
of `foldr`).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1794
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
Re: [GHC] #1782: gmake check-packages fails for ghc-6.8.0.20071017-src on solaris
#1782: gmake check-packages fails for ghc-6.8.0.20071017-src on solaris -+-- Reporter: guest |Owner: simonmar Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.8 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Solaris | Testcase: Architecture: x86 | -+-- Changes (by simonmar): * owner: = simonmar Comment: I'm testing -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1782#comment:1 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
Re: [GHC] #1372: Recompilation checker should consider package versions (and other factors)
#1372: Recompilation checker should consider package versions (and other factors) -+-- Reporter: bringert |Owner: simonmar Type: bug | Status: new Priority: normal|Milestone: 6.8 branch Component: Compiler | Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Comment (by duncan): Yes, currently Cabal does not notice when the .cabal file has been updated without doing configure again. So cabal-setup build is not enough, you have to cabal-setup configure cabal-setup build. I'd like to include this feature in the Cabal dependency analysis project, ie it should automatically rebuild the appropriate things depending on what has been changed in the .cabal file. As for Cabal doing dependency analysis for packages, it does not need to be as accurate as ghc, so long as it is conservatively inaccurate. Then it'll invoke ghc which might decide that there's nothing to do afterall. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1372#comment:14 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
Re: [GHC] #1372: Recompilation checker should consider package versions (and other factors)
#1372: Recompilation checker should consider package versions (and other factors) -+-- Reporter: bringert |Owner: simonmar Type: bug | Status: new Priority: normal|Milestone: 6.8 branch Component: Compiler | Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Comment (by simonmar): Replying to [comment:14 duncan]: Yes, currently Cabal does not notice when the .cabal file has been updated without doing configure again. So cabal-setup build is not enough, you have to cabal-setup configure cabal-setup build. I'd like to include this feature in the Cabal dependency analysis project, ie it should automatically rebuild the appropriate things depending on what has been changed in the .cabal file. This would be pretty easy to do in Cabal as it stands, right? I can submit a patch if you agree. As for Cabal doing dependency analysis for packages, it does not need to be as accurate as ghc, so long as it is conservatively inaccurate. Then it'll invoke ghc which might decide that there's nothing to do afterall. To be conservative and still not invoke GHC on every file, you'd have to check the modification times on the `.hi` files of all package dependencies (possibly all the `.hi` files rather than just the ones that are directly imported, I'm not sure). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1372#comment:15 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
Re: [GHC] #1372: Recompilation checker should consider package versions (and other factors)
#1372: Recompilation checker should consider package versions (and other factors) -+-- Reporter: bringert |Owner: simonmar Type: bug | Status: new Priority: normal|Milestone: 6.8 branch Component: Compiler | Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Comment (by duncan): Replying to [comment:15 simonmar]: This would be pretty easy to do in Cabal as it stands, right? I can submit a patch if you agree. To reconfigure automatically you mean? or just tell users they need to reconfigure? The latter would be easy and I'd gladly accept a patch to do that. To be conservative and still not invoke GHC on every file, you'd have to check the modification times on the `.hi` files of all package dependencies (possibly all the `.hi` files rather than just the ones that are directly imported, I'm not sure). Checking modification times is cheap. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1372#comment:16 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
Re: [GHC] #1395: let ./configure check for a GNUreadline framework
#1395: let ./configure check for a GNUreadline framework +--- Reporter: [EMAIL PROTECTED]|Owner: Type: feature request | Status: reopened Priority: normal |Milestone: 6.8 branch Component: Build System | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: MacOS X | Testcase: Architecture: Multiple | +--- Changes (by guest): * cc: [EMAIL PROTECTED] (removed) Comment: I was not able build a correct binary dist with a local GNUreadline framework, because I could not pass cc- and ld-Flags to the build process that don't end up in `driver/package.conf.inplace`. Furthermore in `compiler/ghci/Linker.lhs` the home directory of the current user should be added to `defaultFrameworkPaths` (line 1141) in order to avoid an unjustified failure message (without even trying to load the framework, which succeeds because it is already loaded by the ghc binary). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1395#comment:10 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
[GHC] #1795: typechecker loops on simple program with fundep
#1795: typechecker loops on simple program with fundep
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.8
Severity: major | Keywords:
Difficulty: Unknown | Os: Multiple
Testcase: yes | Architecture: x86
---+
The program below causes the Renamer/typechecker phase to loop.
Confirmed with GHC 6.8.20070927 on Linux and 6.9.20071018 on Windows (so
I'm not absolutely certain it's present in latest 6.8, but it seems very
likely).
The program has an infinite type - the definition of translate causes
(String, a) to be unified with a. Removing the fundep in MkA causes a
reasonable error to be reported.
{{{
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies,
FlexibleInstances #-}
module X() where
data A a = A
class MkA a b | a - b where
mkA :: a - A b
instance MkA a a where
translate :: (String, a) - A a
translate a = mkA a
}}}
Ganesh
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1795
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
Re: [GHC] #1782: gmake check-packages fails for ghc-6.8.0.20071017-src on solaris
#1782: gmake check-packages fails for ghc-6.8.0.20071017-src on solaris
-+--
Reporter: guest |Owner: igloo
Type: merge | Status: new
Priority: normal|Milestone: 6.8.1
Component: Compiler | Version: 6.8
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Os: Solaris | Testcase:
Architecture: x86 |
-+--
Changes (by simonmar):
* owner: simonmar = igloo
* type: bug = merge
* milestone: = 6.8.1
Comment:
Done:
{{{
Mon Oct 22 06:33:37 PDT 2007 Simon Marlow [EMAIL PROTECTED]
* patch from #1782; fixes check-packages target on Solaris
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1782#comment:2
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
Re: [GHC] #1795: typechecker loops on simple program with fundep
#1795: typechecker loops on simple program with fundep -+-- Reporter: guest |Owner: Type: bug | Status: new Priority: normal|Milestone: 6.8.1 Component: Compiler | Version: 6.8 Severity: major | Resolution: Keywords:| Difficulty: Unknown Os: Multiple | Testcase: yes Architecture: x86 | -+-- Changes (by igloo): * milestone: = 6.8.1 Comment: This also happens with my 6.8.0.20071019, and is a regression since 6.6. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1795#comment:1 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
Re: [GHC] #1395: let ./configure check for a GNUreadline framework
#1395: let ./configure check for a GNUreadline framework
+---
Reporter: [EMAIL PROTECTED]|Owner:
Type: feature request | Status: reopened
Priority: normal |Milestone: 6.8 branch
Component: Build System | Version: 6.8
Severity: normal | Resolution:
Keywords: | Difficulty: Easy (1 hr)
Os: MacOS X | Testcase:
Architecture: Multiple |
+---
Comment (by guest):
Instead of adding and searching the user's home directory is suffices in
compiler/ghci/Linker.lhs (line 1136) to simply ignore the unjustified
failure by:
{{{
Nothing - return Nothing
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1395#comment:11
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
Re: [GHC] #1372: Recompilation checker should consider package versions (and other factors)
#1372: Recompilation checker should consider package versions (and other factors) -+-- Reporter: bringert |Owner: simonmar Type: bug | Status: new Priority: normal|Milestone: 6.8 branch Component: Compiler | Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Comment (by dons): Replying to [comment:13 simonmar]: * X11-extras was updated, the API was changed, the version was not bumped * xmonad was updated to match * it failed to compile against the old X11-extras that's expected, right? So in the past we've had failures of this sort, yes. No version bump in the X11-extras version, then users building without cleaning, getting strange errors. However, now we bump the version on any api change, esp. so for the released stable branch, leading to problems of the second kind: The problem you described seems slightly different: * X11-extras is modified, the version is bumped * xmonad is updated to match (with a dependency on the new version) * `darcs pull xmonad` * without cleaning first, `setup build` Now, Cabal doesn't notice that `xmonad.cabal` has been updated, and hence doesn't notice that it needs to depend on the new version of X11-extras. If this is the case, it's a Cabal bug - Cabal should refuse to build if the `.cabal` file has been modified since the last configure. Right, now that we bump versions properly, the problem is the lack of recompilation in repositories, typically when users darcs pull, and the xmonad .cabal file changes, and then some kind of build failure occurs, or runtime segfault in the worst case. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1372#comment:17 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
[GHC] #1796: Build fails under OS X: Hpc.c:191:0: error: conflicting types for 'hs_hpc_module'
#1796: Build fails under OS X: Hpc.c:191:0: error: conflicting types for 'hs_hpc_module' ---+ Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.8 branch Component: Build System |Version: 6.6.1 Severity: blocker | Keywords: Difficulty: Unknown | Os: MacOS X Testcase:| Architecture: x86 ---+ Have a log: ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict- prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc- Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc- Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I../gmp/gmpbuild -optc-fno-strict-aliasing -H16m -O -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -c Hpc.c -o Hpc.o ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict- prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc- Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc- Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I../gmp/gmpbuild -optc-fno-strict-aliasing -H16m -O -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -c HsFFI.c -o HsFFI.o Hpc.c:191:0: error: conflicting types for 'hs_hpc_module' ../includes/RtsExternal.h:76:0: error: previous declaration of 'hs_hpc_module' was here Hpc.c: In function 'writeTix': Hpc.c:288:0: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'StgWord32' Hpc.c:288:0: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'StgWord32' make[1]: *** [Hpc.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [stage1] Error 1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1796 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
Re: [GHC] #1781: Type equality class leads to non-termination
#1781: Type equality class leads to non-termination +--- Reporter: chak |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | +--- Comment (by guest): Replying to [comment:5 chak]: You may have misunderstood the problem exposed by this bug - maybe my explanation just wasn't clear. The problem is '''not''' with the equality class `E` as such. It's with this particular use in the definition of `plus`, where the signature type contains a type variable that is constrained to be a function by the class context. This is something that has '''never''' worked in GHC, so I doubt that it breaks any existing code. As I understand, this code didn’t make the type checker loop in previous versions of GHC. So maybe there is a new problem in GHC which causes the looping of the type checker in this case, and this problem could also cause the looping with my code. But since you want so, I will file a new bug report. :-) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1781#comment:6 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
[GHC] #1797: type equality test leads to a looping type checker
#1797: type equality test leads to a looping type checker
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.8
Severity: normal| Keywords:
Difficulty: Unknown | Os: Unknown
Testcase:| Architecture: x86
---+
The following code (similar to one of HList’s generic type equality tests)
causes GHC to loop forever (or at least very long) with GHC 6.8.0.20071020
on i386-unknown-mingw32 and GHC 6.8.0.20071019 on i386-unknown-linux:
{{{
{-# LANGUAGE
MultiParamTypeClasses,
FunctionalDependencies,
UndecidableInstances,
OverlappingInstances,
FlexibleInstances,
EmptyDataDecls #-}
data True
data False
class TypeEq type1 type2 result | type1 type2 - result where
typeEq :: type1 - type2 - result
instance TypeEq soleType soleType True where
typeEq _ _ = undefined
instance (TypeCast False result) = TypeEq type1 type2 result where
typeEq _ _ = undefined
class TypeCast type1 type2 | type1 - type2, type2 - type1
instance TypeCast soleType soleType
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1797
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
Re: [GHC] #1662: mistranslation of arrow notation
#1662: mistranslation of arrow notation +--- Reporter: ross |Owner: igloo Type: merge| Status: closed Priority: normal |Milestone: 6.8 branch Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Multiple | Testcase: arrowrun004, arrowpat Architecture: Multiple | +--- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1662#comment:8 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
Re: [GHC] #1450: ^C doesn't result in the cost center stack being printed when running with +RTS -xc
#1450: ^C doesn't result in the cost center stack being printed when running with +RTS -xc ---+ Reporter: SamB|Owner: igloo Type: merge | Status: closed Priority: normal |Milestone: 6.8 branch Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ---+ Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1450#comment:6 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
Re: [GHC] #1468: :browse should browse currently loaded module
#1468: :browse should browse currently loaded module --+- Reporter: [EMAIL PROTECTED] |Owner: igloo Type: merge | Status: closed Priority: normal |Milestone: 6.8 branch Component: GHCi | Version: 6.6.1 Severity: trivial| Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Os: Unknown| Testcase: Architecture: Unknown| --+- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: First merged; second is in the shared testsuite, so no merge needed. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1468#comment:7 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
Re: [GHC] #1784: Duplicate cases for EM_AMD64 and EM_X86_64
#1784: Duplicate cases for EM_AMD64 and EM_X86_64 ---+ Reporter: guest |Owner: igloo Type: merge | Status: closed Priority: normal |Milestone: 6.8 branch Component: Runtime System | Version: 6.8 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Solaris | Testcase: Architecture: x86 | ---+ Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1784#comment:3 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
ghci ':browse *module' does not list items in source order
[trac seems unreachable at the moment, hence good old email] while trying to write a test for an extension of :browse, i encountered an issue with the existing functionality: the order of names is not stable, making it difficult to write meaningful tests for :browse. a reduced test case output are appended below, showing that output order is affected by prior usage, in both 6.6.1 and HEAD. i would prefer for the items to appear in source order, but at the point :browse gets a hand on them, source location information might not be available; sorting by Name would be random due to uniqueIds, and lexicographic sorting would be confusing to users (spreading related items all over the alphabet, instead of keeping the order in which they appear in source and documentation). is there a way to keep the items in source order, within each module (modules themselves could be sorted lexicographically)? claus --- testing :browse $ cat y.hs import Prelude() import Data.Maybe(catMaybes,mapMaybe) $ cat .ghci :t Data.Maybe.mapMaybe $ ghcii.sh --version The Glorious Glasgow Haskell Compilation System, version 6.6.1 $ /cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace --interactive --version The Glorious Glasgow Haskell Compilation System, version 6.9.20071019 $ (echo :l y.hs;echo :browse '*Main') | ghcii.sh -v0 Data.Maybe.mapMaybe :: (a - Maybe b) - [a] - [b] mapMaybe :: (a - Data.Maybe.Maybe b) - [a] - [b] catMaybes :: [Data.Maybe.Maybe a] - [a] $ (echo :l y.hs;echo :browse '*Main') | ghcii.sh -v0 -ignore-dot-ghci catMaybes :: [Data.Maybe.Maybe a] - [a] mapMaybe :: (a - Data.Maybe.Maybe b) - [a] - [b] $ (echo :l y.hs;echo :browse '*Main') | /cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace --inter active -v0 Data.Maybe.mapMaybe :: (a - Maybe b) - [a] - [b] mapMaybe :: (a - Data.Maybe.Maybe b) - [a] - [b] catMaybes :: [Data.Maybe.Maybe a] - [a] $ (echo :l y.hs;echo :browse '*Main') | /cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace --inter active -v0 -ignore-dot-ghci catMaybes :: [Data.Maybe.Maybe a] - [a] mapMaybe :: (a - Data.Maybe.Maybe b) - [a] - [b] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
