Re: [GHC] #1012: ghc panic with mutually recursive modules and template haskell
#1012: ghc panic with mutually recursive modules and template haskell --+- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal| Milestone: _|_ Component: Template Haskell |Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase: TH_import_loop| Architecture: Multiple Os: Multiple | --+- Comment (by simonmar): Since `ModuleB` is outside the `ModuleA/ModuleC` loop, it can import `ModuleA` without creating any new loops, and I bet this will work around the problem and get you unblocked. What's happening is that the dependency analysis isn't figuring out that the real `ModuleA` must be compiled before `ModuleB`. I think the solution is something along the lines of: every module that depends on a module in a cycle, but is not a member of that cycle, should have an implicit dependency on each of the modules in the cycle. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1012#comment:9 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] #1012: ghc panic with mutually recursive modules and template haskell
#1012: ghc panic with mutually recursive modules and template haskell --+- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal| Milestone: 6.8 branch Component: Template Haskell |Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase: TH_import_loop| Architecture: Multiple Os: Multiple | --+- Changes (by simonmar): * milestone: _|_ = 6.8 branch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1012#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
Re: [GHC] #1944: round function causes cblas NaNs
#1944: round function causes cblas NaNs
---+
Reporter: SevenThunders | Owner:
Type: bug| Status: new
Priority: normal | Milestone: 6.8.3
Component: Compiler |Version: 6.8.1
Severity: critical | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86
Os: Windows|
---+
Comment (by simonmar):
Presumably something in the floating-point unit state is changing in a way
that upsets the code in the cblas library. I don't know of anything that
could cause this; the native code generator does in one place generate
code that saves and restores the FPU control word, but that was added in
6.8.2 (see #1910).
To proceed we really need to know what is changing in the FPU state, so
that we can trace it back to the point at which it changed. At the very
least, we need a reproducible test case. I downloaded your files and
tried it, but it looks like I have a DLL missing:
{{{
c:\builds\atlas\Test2maketest
c:\builds\atlas\Test2set CLIB=atlas
c:\builds\atlas\Test2set TopFile=Test2
c:\builds\atlas\Test2set csrc=ctest2.c
c:\builds\atlas\Test2set OutFile=Test2.exe
c:\builds\atlas\Test2dlltool.exe -D atlas.dll -l atlas.lib
c:\builds\atlas\Test2set XFLAGS=-threaded -O -XForeignFunctionInterface
c:\builds\atlas\Test2rem set XFLAGS=-threaded -O -fffi
c:\builds\atlas\Test2ghc -threaded -O -XForeignFunctionInterface -I.
-I..\matri
xstack --make Test2.hs ctest2.c -o Test2.exe -optl-latlas -optl-L.
[1 of 1] Compiling Main ( Test2.hs, Test2.o )
Linking Test2.exe ...
c:\builds\atlas\Test2Test2
c:\builds\atlas\Test2dir
Volume in drive C has no label.
Volume Serial Number is 6041-4C23
Directory of c:\builds\atlas\Test2
03/01/2008 10:38DIR .
03/01/2008 10:38DIR ..
29/11/2007 02:28 5,485,456 atlas.dll
03/01/2008 10:38 1,490 atlas.lib
29/11/2007 02:28 547 ctest2.c
29/11/2007 02:28 721 ctest2.h
03/01/2008 10:38 849 ctest2.o
03/01/2008 10:37 433 index.html
29/11/2007 02:28 309 maketest.bat
03/01/2008 10:38 687,370 Test2.exe
03/01/2008 10:38 502 Test2.exe.manifest
03/01/2008 10:38 1,913 Test2.hi
29/11/2007 02:28 178 Test2.hs
03/01/2008 10:38 4,920 Test2.o
12 File(s) 6,184,688 bytes
2 Dir(s) 47,145,406,464 bytes free
c:\builds\atlas\Test2Test2.exe
c:\builds\atlas\Test2
}}}
Using dependency walker it looks like I don't have MSJAVA.DLL. Although
why I need that, I have no idea.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1944#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] #1898: segfault with +RTS -N2 (related to tryTakeMVar?)
#1898: segfault with +RTS -N2 (related to tryTakeMVar?) +--- Reporter: j.waldmann | Owner: simonmar Type: bug | Status: new Priority: high| Milestone: 6.8.3 Component: Compiler|Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | +--- Changes (by simonmar): * owner: = simonmar Comment: I'm testing a fix for this. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1898#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
Re: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out of range.
#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
-+--
Reporter: mboes| Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.8.3
Component: GHCi |Version: 6.8.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86_64 (amd64)
Os: FreeBSD |
-+--
Comment (by mboes):
Debug output of
{{{
./stage2/ghc-inplace --interactive +RTS -Dl 21 | tee log
}}}
is at [http://code.haskell.org/~mboes/log.bz2] (log too big for attachment
on trac).
Note that FreeBSD, just like OpenBSD, does not define MAP_32BIT and
MAP_ANONYMOUS. I see in Linker.c the following #define:
{{{
#if defined(x86_64_HOST_ARCH) defined(MAP_32BIT)
#define EXTRA_MAP_FLAGS MAP_32BIT
#else
#define EXTRA_MAP_FLAGS 0
#endif
}}}
But then I see an attempt to resolve symbols allocated in high memory
using a bounce sequence:
{{{
// On x86_64, 32-bit relocations are often used, which requires that
// we can resolve a symbol to a 32-bit offset. However, shared
// libraries are placed outside the 2Gb area, which leaves us with a
// problem when we need to give a 32-bit offset to a symbol in a
// shared library.
//
// For a function symbol, we can allocate a bounce sequence inside the
// 2Gb area and resolve the symbol to this. The bounce sequence is
// simply a long jump instruction to the real location of the symbol.
//
// For data references, we're screwed.
//
...
static void*
x86_64_high_symbol( char *lbl, void *addr )
{
x86_64_bounce *bounce;
if ( x86_64_bounce_buffer == NULL ||
x86_64_bb_next_off = X86_64_BB_SIZE ) {
x86_64_bounce_buffer =
mmap(NULL, X86_64_BB_SIZE * sizeof(x86_64_bounce),
PROT_EXEC|PROT_READ|PROT_WRITE,
MAP_PRIVATE|EXTRA_MAP_FLAGS|MAP_ANONYMOUS, -1, 0);
if (x86_64_bounce_buffer == MAP_FAILED) {
barf(x86_64_high_symbol: mmap failed);
}
x86_64_bb_next_off = 0;
}
...
}}}
Since there is no MAP_32BIT on FreeBSD it would seem the above bounce
sequence can get arbitrarily allocated in high memory. Could this be the
problem? I'm way out of my depth here, so please forgive the daftness of
this question, but on my system there are no 32bit libraries at all, only
64bit ones. Hence, could we do away with 32bit relocations entirely?
Hope this helps,
Mathieu
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2013#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] #1999: panic with GADT etc.
#1999: panic with GADT etc. --+- Reporter: jeltsch | Owner: chak Type: bug | Status: new Priority: normal| Milestone: 6.10 branch Component: Compiler |Version: 6.9 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: x86 Os: Linux | --+- Changes (by simonpj): * owner: = chak Comment: However, it may well not work in the HEAD, where Manuel is busy ripping out the old implementation of GADTs, in favour of the new type-function- based machinery. So I'm assigning this to Manuel; it'd be good to make a test case out of it too. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1999#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] #1898: segfault with +RTS -N2 (related to tryTakeMVar?)
#1898: segfault with +RTS -N2 (related to tryTakeMVar?)
+---
Reporter: j.waldmann | Owner: igloo
Type: merge | Status: new
Priority: high| Milestone: 6.8.3
Component: Compiler|Version: 6.8.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86
Os: Linux |
+---
Changes (by simonmar):
* owner: simonmar = igloo
* type: bug = merge
Comment:
Fixed:
{{{
Thu Jan 3 03:27:17 PST 2008 Simon Marlow [EMAIL PROTECTED]
* FIX #1898: add a missing UNTAG_CLOSURE() in checkBlackHoles
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1898#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] #2006: unreachable GADT pattern clauses show up as warnings with -Wall
#2006: unreachable GADT pattern clauses show up as warnings with -Wall --+- Reporter: ryani | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.10 branch Component: Compiler |Version: 6.8.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by simonpj): * milestone: 6.8 branch = 6.10 branch Comment: Quite right. The non-exhaustive pattern warning comes from a part of the compiler that needs a serious overhaul. See #595. In particular, it's utterly unaware of GADTs, so it's going to produce spurious warnings, and will continue to do so until it is overhauled. We definitely won't fix this on the 6.8 branch. Probably it needs a volunteer. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2006#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: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
Hi Christian, On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote: Judah's framework (2342543 Bytes) http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip should replace (my old one) http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip Done! Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking
#595: Overhaul GHC's overlapping/non-exhaustive pattern checking --+- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal| Milestone: _|_ Component: Compiler |Version: None Severity: normal| Resolution: None Keywords: warnings | Difficulty: Difficult (1 week) Testcase: N/A | Architecture: Unknown Os: Unknown | --+- Comment (by simonpj): And #2006 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/595#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
Re: [GHC] #2000: -funfolding-update-in-place badly documented
#2000: -funfolding-update-in-place badly documented
--+-
Reporter: m4dc4p| Owner: igloo
Type: merge | Status: new
Priority: normal| Milestone: 6.8.3
Component: Compiler |Version: 6.8.1
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Architecture: x86
Os: Windows |
--+-
Changes (by simonpj):
* type: bug = merge
Comment:
It's an obsolete flag that does nothing. I'll remove the documentation:
{{{
Thu Jan 3 16:00:36 GMT 2008 [EMAIL PROTECTED]
* Remove -funfolding-update-in-place flag documentation
}}}
Merge to 6.8 branch, pls.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2000#comment:4
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] #2011: [6.8.1 regression] panic: lookupVers1 base:GHC.Prim sym{tc}
#2011: [6.8.1 regression] panic: lookupVers1 base:GHC.Prim sym{tc}
--+-
Reporter: simonmar | Owner: igloo
Type: merge | Status: new
Priority: high | Milestone: 6.8.3
Component: Compiler |Version: 6.8.2
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Architecture: Unknown
Os: Unknown |
--+-
Changes (by simonpj):
* owner: simonpj = igloo
* type: bug = merge
Comment:
The patch is this one. Ian, please merge to 6.8 branch.
{{{
Thu Dec 20 16:43:07 GMT 2007 [EMAIL PROTECTED]
* Fix nasty recompilation bug in MkIface.computeChangedOccs
MERGE to 6.8 branch
In computeChangedOccs we look up the old version of a Name.
But a WiredIn Name doesn't have an old version, because WiredIn things
don't appear in interface files at all.
Result: ghc-6.9: panic! (the 'impossible' happened)
(GHC version 6.9 for x86_64-unknown-linux):
lookupVers1 base:GHC.Prim chr#{v}
This fixes the problem. The patch should merge easily onto the branch.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2011#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] #793: Use gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs?
#793: Use gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs? +--- Reporter: simonmar| Owner: simonmar Type: task| Status: new Priority: normal | Milestone: 6.8 branch Component: Runtime System |Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Architecture: Unknown Os: Unknown | +--- Comment (by igloo): I don't think we should bundle it. It's the sort of thing where more obscure platforms need the latest version, and we don't another thing we have to make sure we keep up-to-date. Also, for the common case (including Windows users) it isn't necessary to have it, as the existing code can be used instead. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/793#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] #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) Testcase: | Architecture: Multiple Os: MacOS X | -+-- Comment (by guest): Replying to [comment:25 maeder]: My modification of `utils/hsc2hs/Main.hs` (probably) caused the problem reported in http://article.gmane.org/gmane.comp.lang.haskell.cafe/34373 Cabal already handles this type of problem by passing different flags based on whether `hsc2hs` is using `gcc` or `ghc`. This is done in `Distribution.Simple.PreProcess.ppHsc2hs` and `Simple.Program.hsc2hsProgram`. Perhaps Cabal should add the `-F$HOME/Library/Frameworks` instead of `hsc2hs` itself? See http://hackage.haskell.org/trac/hackage/ticket/189 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1395#comment:26 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) Testcase: | Architecture: Multiple Os: MacOS X | -+-- Comment (by guest): By the way; I wrote the previous comment while logged in as `guest`, but forgot to sign it. -Judah -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1395#comment:27 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] #1987: GHCi's config file in AppData\ghc folder on Windows
#1987: GHCi's config file in AppData\ghc folder on Windows -+-- Reporter: felixmar | Owner: Type: feature request | Status: new Priority: low | Milestone: 6.10 branch Component: GHCi |Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -+-- Changes (by ross): * type: proposal = feature request -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1987#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: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
Hello, Thanks everybody. However, I believe that using a modified readline library is debatable, mainly because it adds the burden of keeping this library up-to-date to the GHC maintenance process. Having a renamed library is one thing and it does not seem that also modifying the contents of the library is an improvement. For me to consider this idea, it should be the very last solution, every other stone having been turned. And I certainly believe that stones remain to be turned in this case. I would very much like to hear your comments to this. In addition, if you must replace this framework with another with different contents, I would suggest the use of some versioning scheme. Otherwise is seems that a lot of confusion could result. Thanks and best regards Thorkil On Thursday 03 January 2008 16:18, Ian Lynagh wrote: Hi Christian, On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote: Judah's framework (2342543 Bytes) http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip should replace (my old one) http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip Done! Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9
#1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a
PPC Mac OS X 10.5 Leopard as part of GHC 6.9
-+--
Reporter: thorkilnaur | Owner: thorkilnaur
Type: bug | Status: new
Priority: high | Milestone: 6.8.3
Component: Compiler |Version: 6.9
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: powerpc
Os: MacOS X |
-+--
Comment (by eelco):
I haven't spent much time on this (because I compiling GHC wasn't the
final goal ;), but the compiler built with 'quickest' gave some strange
errors concerning interface files when trying to build HAppS. So I tried
building 6.8.2 again, again with ld_classic, but now with build flavor
'quick'. I had to restart the build 3 or 4 times, since it segfaulted on
(seemingly) random files. After that I tried building HAppS again.
Unfortunately, I got stuck at the same point, this time with a panic.
{{{
[10 of 18] Compiling HAppS.State.Transaction (
src/HAppS/State/Transaction.hs, dist/build/HAppS/State/Transaction.o )
src/HAppS/State/Transaction.hs:264:42:
Warning: Defined but not used: `logger'
src/HAppS/State/Transaction.hs:264:52:
Warning: Defined but not used: `ev'
ghc-6.8.2: panic! (the 'impossible' happened)
(GHC version 6.8.2 for powerpc-apple-darwin):
splitFunTy
ntbase:GHC.Conc.STM{tc r2T} base:GHC.Base.(){(w) tc 40}
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1958#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
