Re: [GHC] #1131: newArray_ allocates an array full of garbage
#1131: newArray_ allocates an array full of garbage ---+ Reporter: igloo |Owner: Type: bug | Status: new Priority: high|Milestone: 6.8 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ---+ Comment (by guest): While I don't think it is good practice to rely on newArray_ returning random values, the documentation clearly states: newArray :: Ix i = (i, i) - e - m (a i e) Builds a new array, with every element initialised to the supplied value. newArray_ :: Ix i = (i, i) - m (a i e) Builds a new array, with every element initialised to undefined. Possibly, newArray_ shouldn't be defined at all for unboxed arrays, but since it is, I think the current implementation is the only reasonable. (Presumably, newArray_'s raison d'être is that it is faster than newArray?) I don't think this is a bug at all, and I don't understand at all why it is given a 'high' priority. Stefan should use newArray, and iampure should expect his programs to break without warning in the future :-) -k -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1131 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] #1488: Code that won't ever be executed should not give rise to constraints
#1488: Code that won't ever be executed should not give rise to constraints
--+-
Reporter: [EMAIL PROTECTED] |Owner:
Type: feature request| Status: new
Priority: normal |Milestone:
Component: Compiler | Version: 6.6.1
Severity: normal | Resolution:
Keywords: | Difficulty: Moderate (1 day)
Os: Unknown| Testcase:
Architecture: Unknown|
--+-
Old description:
In the code
a x = let b = show x in 5,
ghci derives:
a :: (Show a, Num t) = a - t, which is correct, but I think the rules
should be slightly altered, since in reality giving something to a which
is not an instance of Show wouldn't be a problem, since it's not used in
the first place.
One important application of this is testing a general data structure for
one specific element type with assertions in the the general code and
having a switch to turn generic and non-generic mode on and off.
Unfortunately, this approach doesn't work today, since all kinds of
constraints that are essentially part of the debugging process get added.
Since deciding whether a certain variable is used is very easy in this
setting(for example CPP macros that expand into if debugging, where
debugging will have a constant value. (I don't expect you to solve the
Halting Problem).
New description:
In the code
{{{
a x = let b = show x in 5,
}}}
ghci derives:
{{{
a :: (Show a, Num t) = a - t,
}}}
which is correct, but I think the rules should be slightly altered, since
in reality giving something to a which is not an instance of Show wouldn't
be a problem, since it's not used in the first place.
One important application of this is testing a general data structure for
one specific element type with assertions in the the general code and
having a switch to turn generic and non-generic mode on and off.
Unfortunately, this approach doesn't work today, since all kinds of
constraints that are essentially part of the debugging process get added.
Since deciding whether a certain variable is used is very easy in this
setting(for example CPP macros that expand into if debugging, where
debugging will have a constant value. (I don't expect you to solve the
Halting Problem).
Comment (by simonpj):
Lennart adds: And ghci gives the only sensible answer. Once you start
trying to be clever you're on the slippery slope to undecidability. How
would one know where to stop? I would be most perturbed if Haskell were
to try and ignore unused variables.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1488
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] #1437: Build failures on Mac OS X 10.5
#1437: Build failures on Mac OS X 10.5 --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: normal |Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X| Testcase: Architecture: x86| --+- Changes (by guest): * cc: [EMAIL PROTECTED] = [EMAIL PROTECTED],[EMAIL PROTECTED] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1437 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] #1489: Impossible happened
#1489: Impossible happened
+---
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug| Status: new
Priority: highest| Milestone:
Component: Compiler |Version: 6.7
Severity: blocker| Keywords:
Difficulty: Unknown| Os: Unknown
Testcase: | Architecture: Unknown
+---
ghc-6.7.20070702: panic! (the 'impossible' happened)
(GHC version 6.7.20070702 for i386-unknown-linux):
nameModule $dMonad{v a1BV5}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Unfortunately, I have no test case, but it happened during the evaluation
of something of type IO ([(Int, Int)]) which uses undecidable instances,
functional dependencies and the no monomorphism restriction.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1489
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] #1489: Impossible happened
#1489: Impossible happened --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: highest|Milestone: Component: Compiler | Version: 6.7 Severity: blocker| Resolution: Keywords: | Difficulty: Unknown Os: Unknown| Testcase: Architecture: Unknown| --+- Comment (by [EMAIL PROTECTED]): It appears that merely evaluating foo = putStrLn hi triggers the bug, but only when inside a module that uses those extensions in combination with my code. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1489 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] #1489: Impossible happened
#1489: Impossible happened --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: highest|Milestone: Component: GHCi | Version: 6.7 Severity: blocker| Resolution: Keywords: | Difficulty: Unknown Os: Unknown| Testcase: Architecture: Unknown| --+- Changes (by guest): * component: Compiler = GHCi -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1489 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] #1131: newArray_ allocates an array full of garbage
#1131: newArray_ allocates an array full of garbage
---+
Reporter: igloo |Owner:
Type: bug | Status: closed
Priority: high|Milestone: 6.8
Component: libraries/base | Version: 6.6
Severity: normal | Resolution: fixed
Keywords: | Difficulty: Unknown
Os: Unknown | Testcase: arr018
Architecture: Unknown |
---+
Changes (by simonmar):
* resolution: = fixed
* testcase: = arr018
* status: new = closed
Comment:
Fixed:
{{{
Wed Jul 4 11:20:20 BST 2007 Simon Marlow [EMAIL PROTECTED]
* FIX #1131 (newArray_ allocates an array full of garbage)
Now newArray_ returns a deterministic result in the ST monad, and
behaves as before in other contexts. The current newArray_ is renamed
to unsafeNewArray_; the MArray class therefore has one more method
than before.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1131
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] #1490: Install with Cabal broken on Windows
#1490: Install with Cabal broken on Windows
+---
Reporter: guest | Owner:
Type: bug| Status: new
Priority: normal | Milestone:
Component: libraries (other) |Version: 6.7
Severity: normal | Keywords:
Difficulty: Unknown| Os: Windows
Testcase: | Architecture: Unknown
+---
After building a Cabal package with ghc 2007-07-02 I tried to install it.
It fails.
{{{
$ ./setup install -v2
directory dist\doc\html\paradise does exist: False
Installing: C:\LA\foo\Haskell\paradise-1.0.15\ghc-6.7.20070702
C:\LA\foo\Haskell\bin paradise-1.0.15...
Creating C:\LA\foo\Haskell\paradise-1.0.15\ghc-6.7.20070702\include (and
its parents)
setup: C:\: createDirectory: permission denied (Permission denied)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1490
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] #1489: Impossible happened
#1489: Impossible happened --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: highest|Milestone: Component: GHCi | Version: 6.7 Severity: blocker| Resolution: Keywords: | Difficulty: Unknown Os: Unknown| Testcase: Architecture: Unknown| --+- Comment (by guest): During compilation (ghc --make) the following happened: ghc-6.7.20070702: panic! (the 'impossible' happened) (GHC version 6.7.20070702 for i386-unknown-linux): initC: srt It might be the case that my compiled version of GHC is simply broken, but since I didn't do anything odd and just followed build instructions, I report it. This is another issue from the one reported above, but they are probably related. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1489 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] #1491: Extension RecordWildCards is broken
#1491: Extension RecordWildCards is broken
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.7
Severity: normal| Keywords:
Difficulty: Unknown | Os: Windows
Testcase:| Architecture: Unknown
---+
The -XRecordWildCards extension is broken (unlike the patch I sent :)).
Try these modules:
{{{
module M1 where
data T = T { a :: Int }
module M2 where
import M1
f T{..} = a + 1
}}}
Compiling these gives
{{{
ghc -XRecordWildCards --make M2.hs
[1 of 2] Compiling M1 ( M1.hs, M1.o )
[2 of 2] Compiling M2 ( M2.hs, M2.o )
M2.hs:4:2: Not in scope: `a'
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1491
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] #1490: Install with Cabal broken on Windows
#1490: Install with Cabal broken on Windows --+- Reporter: guest |Owner: Type: bug| Status: new Priority: normal |Milestone: Component: libraries (other) | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows| Testcase: Architecture: Unknown| --+- Changes (by guest): * cc: = [EMAIL PROTECTED] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1490 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] #1046: Make array indexing immune to seg-faults
#1046: Make array indexing immune to seg-faults +--- Reporter: simonpj |Owner: Type: feature request | Status: new Priority: high |Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | +--- Changes (by Isaac Dupree): * cc: [EMAIL PROTECTED] = [EMAIL PROTECTED], [EMAIL PROTECTED] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1046 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] #1177: All I/O requests must complete before shutdown on Windows
#1177: All I/O requests must complete before shutdown on Windows ---+ Reporter: simonmar|Owner: simonmar Type: bug | Status: new Priority: high|Milestone: 6.8 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: Multiple| ---+ Changes (by guest): * cc: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] = [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1177 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] #1492: It's impossible to get the ghc source with darcs on windows
#1492: It's impossible to get the ghc source with darcs on windows
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: high | Milestone:
Component: Compiler |Version: 6.7
Severity: normal| Keywords:
Difficulty: Unknown | Os: Unknown
Testcase:| Architecture: Unknown
---+
Annoyingly darcs crashes every time I try to get the ghc sources. This is
a problem with both darcs 1.0.8 and 1.0.9
{{{
$ darcs get --partial http://darcs.haskell.org/ghc
This is the GHC darcs repository (HEAD branch)
For more information, visit the GHC developer wiki at
http://hackage.haskell.org/trac/ghc
**
Copying patch 210 of 210... done.
Applying patch 42 of 209... darcs.exe: bug in darcs!
Impossible case at PatchRead.lhs:58 compiled 23:01:08 Jun 4 2007
Please report this to [EMAIL PROTECTED],
If possible include the output of 'darcs --exact-version'.
}}}
Perhaps creating a new snapshot point could fix it?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1492
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: Type: bug | Status: new Priority: normal |Milestone: Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ---+ Changes (by guest): * cc: = [EMAIL PROTECTED] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1450 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] #1097: enumFrom on basic numeric types should be strict
#1097: enumFrom on basic numeric types should be strict --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: reopened Priority: normal |Milestone: Not GHC Component: libraries/base | Version: 6.6 Severity: minor | Resolution: Keywords: enum strictness| Difficulty: Easy (1 hr) Os: Unknown| Testcase: lib/should_run/enum04 Architecture: Unknown| --+- Changes (by guest): * cc: = [EMAIL PROTECTED] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1097 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] #1035: Win32 package doesn't appear in the online library docs
#1035: Win32 package doesn't appear in the online library docs --+- Reporter: simonmar |Owner: Type: bug| Status: new Priority: normal |Milestone: Not GHC Component: Documentation | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown| Testcase: Architecture: Unknown| --+- Changes (by guest): * cc: = [EMAIL PROTECTED] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1035 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] #1489: Impossible happened
#1489: Impossible happened --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: highest|Milestone: Component: GHCi | Version: 6.7 Severity: blocker| Resolution: Keywords: | Difficulty: Unknown Os: Unknown| Testcase: Architecture: Unknown| --+- Comment (by simonpj): Dear iampure, (I wonder what your real name is!) I'm sorry that GHC crashes on you, but it's extremely rare for to be able to fix a bug without being able to reproduce it. If you want us to look into this, there's not alternative to tar'ing up your files and attaching them to this report, adding repro instructions. Or email us direct if it's secret. Without that there is literally nothing we can do to help you. Meanwhile, make sure you compile '''everything''' with `-dcore-lint`. That often shows up a bug much earlier than otherwise. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1489 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] #912: Build system is missing various dependencies
#912: Build system is missing various dependencies -+-- Reporter: simonmar |Owner: Type: bug | Status: new Priority: low |Milestone: _|_ Component: Build System | Version: 6.5 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Multiple | Testcase: N/A Architecture: Multiple | -+-- Comment (by claus): i guess i thought of this as a general recompile might not work ticket, with a high priority, but a low probability of being fixed completely in a near future milestone. it seems to be the only general build system ticket, so perhaps it would be the right place to collect issues like distclean residues, or anything else that hinders rebuilds? having a limited number of permanent general build-related tickets seems preferable to having large numbers of very specialized tickets? btw, it took me a moment to figure out how to get all tickets related to build system. perhaps there could be a preconfigured by component list of tickets? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/912 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] #1493: Int with Prelude-functions works, but Integer with generic-list-functions doesn't
#1493: Int with Prelude-functions works, but Integer with generic-list-functions
doesn't
--+-
Reporter: guest| Owner:
Type: support request | Status: new
Priority: low | Milestone:
Component: Prelude |Version: 6.6.1
Severity: normal | Keywords:
Difficulty: Unknown | Os: Windows
Testcase: | Architecture: x86_64 (amd64)
--+-
Hello,
I've written a program for fast online multiplication of real numbers, it
should produce for an infinite input-sequence an infinite output-sequence.
If I'm using Integer with related generic-list-functions, computation
stops at step 32777. Windows Task-Manager tells me: CPU-Usage 100% ,
Memory-Allocation increasing.
After a few minutes over 600MB memory is used by my program.
But if I'm using Int with Prelude-functions computation doesn't stop and
this is exactly what I'm expecting.
I tried to overwrite the type of the Prelude functions /length/, /take/
etc. to Integer, but the same problem at the same step occurs.
A friend of mine compiled my program under Linux and got this error
message:
32779 : 1 1 ---32776-- 0
32780 : 1 0 ---32777-- -1
Main: Ix{Integer}.index: Index (32766) out of range ((0,32765))
I don't know, whether this is a bug nor where the problem exactly is.
My Source-Code is avaialable under [www.romeinf04.de].
Best regards,
Roman
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1493
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] #1494: panic! (the 'impossible' happened)
#1494: panic! (the 'impossible' happened)
+---
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug| Status: new
Priority: highest| Milestone:
Component: GHCi |Version: 6.7
Severity: blocker| Keywords:
Difficulty: Unknown| Os: Unknown
Testcase: | Architecture: Unknown
+---
After hours of reducing my code, I finally was able to make a small test
case. I am essentially stuck if this doesn't get fixed soon.
Output:
ghc-6.7.20070702: panic! (the 'impossible' happened)
(GHC version 6.7.20070702 for i386-unknown-linux):
nameModule $dMonad{v a3hFy}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1494
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] #1454: Confusing or bug: :t and :i don't return same type
#1454: Confusing or bug: :t and :i don't return same type --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: normal |Milestone: Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown| Testcase: Architecture: Unknown| --+- Comment (by [EMAIL PROTECTED]): So GHC generates all the constraints arising from the expression and then abstracts over them. There's no reason for it to keep them in the same order, and it doesn't. Mabye this is what iampure (I wonder what your real name is) is tripping over? No, I am not tripping over this. It's exactly as I described in a comment above. (06/22/07 15:54:38) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1454 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
stg_ap_pp_ret
Hello, I've been seeing this a lot: interactive: internal error: stg_ap_pp_ret (GHC version 6.6.1 for i386_unknown_linux) Sometimes it seems to go away when I remove .o and .hi files and recompile, but it keeps coming back when I make edits and/or compile with different optimisation options or something. $ uname -a Linux taisa 2.6.20-1-686 #1 SMP Tue Apr 24 21:52:11 UTC 2007 i686 GNU/Linux $ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) Frederik ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1489: Impossible happened
#1489: Impossible happened --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: highest|Milestone: Component: GHCi | Version: 6.7 Severity: blocker| Resolution: Keywords: | Difficulty: Unknown Os: Unknown| Testcase: Architecture: Unknown| --+- Comment (by [EMAIL PROTECTED]): Dear Simon, On http://hackage.haskell.org/trac/ghc/ticket/1494 you can find a reproducible 500 bytes test case. #1489 is most likely fixed when #1494 is. Thank you for the -dcore-lint hint. As for my real name, I'd rather not have insert search engine turn up lots of results when someone searches for my name. If someone would spend some time finding out my name, they would probably succeed however. If you can send me an email address that you will actually read and respond too, I will give you my name. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1489 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] #1035: Win32 package doesn't appear in the online library docs
#1035: Win32 package doesn't appear in the online library docs --+- Reporter: simonmar |Owner: Type: bug| Status: closed Priority: normal |Milestone: Not GHC Component: Documentation | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Os: Unknown| Testcase: Architecture: Unknown| --+- Changes (by igloo): * resolution: = fixed * status: new = closed Comment: I did this for the 6.6.1 release, and it's now a step in the release procedure. `libraries/gen_contents_index` takes care of actually updating the contents and index pages. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1035 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] #930: ghc-6.6: panic! (the 'impossible' happened) mkWWcpr: not a product GHC-Brian-6.5.1:IdInfo.IdInfo{tc rfD}
#930: ghc-6.6: panic! (the 'impossible' happened) mkWWcpr: not a product GHC-
Brian-6.5.1:IdInfo.IdInfo{tc rfD}
---+
Reporter: briansmith |Owner:
Type: bug | Status: new
Priority: high|Milestone: 6.8
Component: Compiler| Version: 6.5
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Os: Unknown | Testcase:
Architecture: Unknown |
---+
Changes (by Isaac Dupree):
* cc: = [EMAIL PROTECTED]
Comment:
It would be convenient for GHC to be able to compile itself with --make,
to help working/testing on #1405 (possibly involving Cabal...).
Alternatively #1409 could work too.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/930
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] #1454: Confusing or bug: :t and :i don't return same type
#1454: Confusing or bug: :t and :i don't return same type --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: normal |Milestone: Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown| Testcase: Architecture: Unknown| --+- Comment (by simonpj): OK, so it's not that. Then I can't see how to make progress without more information. At the very least, can you show a screen dump of what you see, please? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1454 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] #1454: Confusing or bug: :t and :i don't return same type
#1454: Confusing or bug: :t and :i don't return same type --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: normal |Milestone: Component: GHCi | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Unknown| Testcase: Architecture: Unknown| --+- Changes (by [EMAIL PROTECTED]): * severity: normal = minor Comment: I don't have the code anymore that generated that. (I realize it would have been better to make a snapshot and put it aside for some time). I suggest you to stop spending time on this until someone(maybe me) puts a test case here. I set severity to minor, since that fits better. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1454 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] #1454: Confusing or bug: :t and :i don't return same type
#1454: Confusing or bug: :t and :i don't return same type --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: closed Priority: normal |Milestone: Component: GHCi | Version: 6.6.1 Severity: minor | Resolution: worksforme Keywords: | Difficulty: Unknown Os: Unknown| Testcase: Architecture: Unknown| --+- Changes (by igloo): * resolution: = worksforme * status: new = closed Comment: Please reopen this bug if you (anyone) finds a testcase. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1454 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] #1496: System FC{Newtypes,TypeFamilies} is unsound
#1496: System FC{Newtypes,TypeFamilies} is unsound
---+
Reporter: sorear| Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.7
Severity: normal| Keywords:
Difficulty: Unknown | Os: Unknown
Testcase:| Architecture: Unknown
---+
{{{
{-# OPTIONS_GHC -ftype-families #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
data family Z :: * - *
class IsInt t where
isInt :: c Int - c t
instance IsInt Int where isInt = id
newtype Moo = Moo Int deriving(IsInt)
newtype instance Z Int = ZI Double
newtype instance Z Moo = ZM (Int,Int)
main = case isInt (ZI 4.0) of ZM tu - print tu
}}}
{{{
[EMAIL PROTECTED]:/tmp$ ghc -dcore-lint Z.hs
[EMAIL PROTECTED]:/tmp$ ./a.out
Segmentation fault
[EMAIL PROTECTED]:/tmp$ ghc -V
The Glorious Glasgow Haskell Compilation System, version 6.7.20070612
[EMAIL PROTECTED]:/tmp$
}}}
It does not appear possible to tickle this without using the newtype-
deriving
hack, but as the resulting core passes Core Lint this is othogonal to that
bug.
The family of axioms produced is inconsistant:
{{{
(from the instances)
Z Int ~ Double
Z Moo ~ (Int,Int)
(from the newtype)
Moo ~ Int
(production REFL in the FC(X) paper)
Z ~ Z
(production COMP)
Z Moo ~ Z Int
(production TRANS)
Z Moo ~ Double
(production SYM)
Double ~ Z Moo
(production TRANS)
Double ~ (Int,Int)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1496
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] #1496: Newtypes and type families combine to produce inconsistent FC(X) axiom sets
#1496: Newtypes and type families combine to produce inconsistent FC(X) axiom
sets
+---
Reporter: sorear |Owner:
Type: bug | Status: new
Priority: normal |Milestone:
Component: Compiler (Type checker) | Version: 6.7
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Os: Unknown | Testcase:
Architecture: Unknown |
+---
Changes (by sorear):
* component: Compiler = Compiler (Type checker)
* summary: System FC{Newtypes,TypeFamilies} is unsound = Newtypes and
type families combine to produce inconsistent
FC(X) axiom sets
Old description:
{{{
{-# OPTIONS_GHC -ftype-families #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
data family Z :: * - *
class IsInt t where
isInt :: c Int - c t
instance IsInt Int where isInt = id
newtype Moo = Moo Int deriving(IsInt)
newtype instance Z Int = ZI Double
newtype instance Z Moo = ZM (Int,Int)
main = case isInt (ZI 4.0) of ZM tu - print tu
}}}
{{{
[EMAIL PROTECTED]:/tmp$ ghc -dcore-lint Z.hs
[EMAIL PROTECTED]:/tmp$ ./a.out
Segmentation fault
[EMAIL PROTECTED]:/tmp$ ghc -V
The Glorious Glasgow Haskell Compilation System, version 6.7.20070612
[EMAIL PROTECTED]:/tmp$
}}}
It does not appear possible to tickle this without using the newtype-
deriving
hack, but as the resulting core passes Core Lint this is othogonal to
that bug.
The family of axioms produced is inconsistant:
{{{
(from the instances)
Z Int ~ Double
Z Moo ~ (Int,Int)
(from the newtype)
Moo ~ Int
(production REFL in the FC(X) paper)
Z ~ Z
(production COMP)
Z Moo ~ Z Int
(production TRANS)
Z Moo ~ Double
(production SYM)
Double ~ Z Moo
(production TRANS)
Double ~ (Int,Int)
}}}
New description:
Given:
{{{
{-# OPTIONS_GHC -ftype-families #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
data family Z :: * - *
newtype Moo = Moo Int
newtype instance Z Int = ZI Double
newtype instance Z Moo = ZM (Int,Int)
}}}
We generate the axioms:
{{{
(from the instances)
Z Int ~ Double
Z Moo ~ (Int,Int)
(from the newtype)
Moo ~ Int
}}}
And can prove:
{{{
(production REFL in the FC(X) paper)
Z ~ Z
(production COMP)
Z Moo ~ Z Int
(production TRANS)
Z Moo ~ Double
(production SYM)
Double ~ Z Moo
(production TRANS)
Double ~ (Int,Int)
}}}
Tickling this seems to require the newtype cheat, but the inconsistant
axioms
allow code to pass Core Lint and still crash:
{{{
newtype Moo = Moo Int deriving(IsInt)
class IsInt t where
isInt :: c Int - c t
instance IsInt Int where isInt = id
main = case isInt (ZI 4.0) of ZM tu - print tu
}}}
{{{
[EMAIL PROTECTED]:/tmp$ ghc -dcore-lint Z.hs
[EMAIL PROTECTED]:/tmp$ ./a.out
Segmentation fault
[EMAIL PROTECTED]:/tmp$ ghc -V
The Glorious Glasgow Haskell Compilation System, version 6.7.20070612
[EMAIL PROTECTED]:/tmp$
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1496
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
