Re: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
(Let's discuss this openly on glasgow-haskell-users) I'm not happy about this framework hick-hack either. I've only pushed it, because we needed a readline solution on macs. The alternative is to use static linking of gmp (as suggested by chak) _and_ readline (version 5), so that user programs are also statically linked with these libs. Nobody supplied a binary distribution so far, though. I only supplied the binary distributions that I (naively) made anyway. Regarding this actual GNUreadline-framework.zip replacement, this is harmless and seems to matter only for those who build ghc with frameworks (as only the inclusion of header files changed) In any case we should strive to fix the frameworks issues _and_ add support for static linking of gmp, readline and possibly other libs (plus license issues). HTH Christian Thorkil Naur wrote: 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] #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 simonmar): See also Greg Wright's email in which he mentions exactly this problem: [http://www.haskell.org/pipermail/glasgow-haskell- users/2007-April/012291.html] In the HEAD, the fragment of code mentioned above is now gone, in favour of a more general mechanism. You want the patch entitled add PIC relocations for x86_64, and use a simpler hack in place of x86_64_high_symbol() from HEAD. However, this on its own won't be enough: when we allocate memory for objects with `mmap()`, we need to get memory in the low 2Gb, which is why we use `MAP_32BIT` on Linux. I'm not sure what the right way to do this on *BSD is, but you could try adding a hint address to the `mmap()` call, something in the low 2Gb, as Greg suggested in his mail above. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2013#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
Re: [GHC] #1980: sporadic segmentation faults
#1980: sporadic segmentation faults +--- Reporter: maeder | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System |Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple| +--- Changes (by maeder): * os: Linux = Multiple * architecture: x86 = Multiple Comment: relevant for Macs and Solaris, too -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1980#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
[GHC] #2016: GHC generates bad code for pointer manipulations from .cmm
#2016: GHC generates bad code for pointer manipulations from .cmm
---+
Reporter: wb.kloke| Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler| Version: 6.8.2
Severity: major |Keywords:
Difficulty: Unknown |Testcase:
Architecture: x86_64 (amd64) | Os: FreeBSD
---+
In files rts/StgStdThunks.cmm (and rts/StgMiscClosures.cmm also) a
natively booted x86_64 compiler generates the following wrong assembler
output:
{{{
.text
.align 8
.quad 0
.quad 34
.globl stg_sel_ret_0_upd_info
stg_sel_ret_0_upd_info:
movl $4294967288,%eax
movq %rbx,%rcx
andq %rax,%rcx
movq 8(%rcx),%rbx
addq $8,%rbp
...
}}}
The correct code for the movl line is
{{{
movq $-8,%rax
}}}
The real output from a correct compiler (such as the stage1 compiler
crosscompiled from i386) is slightly different due to optimisation, but
equivalent to my correction.
I checked this bug with different compilation flags in the stage1 and
stage2 creation phase (with -fasm or -fvia-C). I am not sure whether the
bug is present in other x86_64 OSs, which are supported for longer than
FreeBSD. But it is easy to check. Just compile the file with -S with a
stage2 compiler.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2016
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: closed
Priority: normal| Milestone: 6.8 branch
Component: Template Haskell |Version: 6.8.2
Severity: normal| Resolution: fixed
Keywords:| Difficulty: Unknown
Testcase: TH_import_loop| Architecture: Multiple
Os: Multiple |
--+-
Changes (by simonpj):
* status: reopened = closed
* resolution: = fixed
Comment:
Simon is right: B.hs depends on C.hs, which depends on A.hs-boot. I think
it's quite accidental that A happens to be compiled before B in your
curiously enough case, but after B in your original case.
All you need do is to make B depend on A, thus
{{{
{-# LANGUAGE TemplateHaskell #-}
module ModuleB where
import ModuleC
import ModuleA
$(nothing)
}}}
and it all works fine. Use -v to see the compilation order.
I will clarify the documentation, thus:
You can only run a function at compile time if it is imported from
another module ''that is not part of a mutually-recursive group of modules
that includes the module currently being compiled''. Furthermore, all of
the modules of the mutually-recursive group must be reachable by non-
SOURCE imports from the module where the splice is to be run.
{{{
Fri Jan 4 12:19:39 GMT 2008 [EMAIL PROTECTED]
* Document SOURCE pragma; clarify TH behavior for
mutually-recurive modules (Trac #1012)
}}}
It's not clear to me how to improve the error message, at least not
without adding more plumbing to say I'm in a Template Haskell splice.
Let's see if it happens again.
Meanwhile I'll close the bug.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1012#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] #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 simonmar): Replying to [comment:8 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. I agree, except that I've just done a bit of digging and libffi would fix: * #1288 (stdcall in GHCi on Windows) * #738 (SELinux) * #631 (FFI in GHCi unregisterised) For #738, we could pinch the code from `libffi` which works around the issue (the license is unrestrictive). For #1288, I'd rather just use `libffi` than implement it myself, but that means requiring `libffi` on Windows. For #631, I assume it's not a problem to require `libffi` for unregisterised builds. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/793#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] #2004: Pattern matching against GADTs without -XGADTs has odd behavior.
#2004: Pattern matching against GADTs without -XGADTs has odd behavior. -+-- Reporter: guest| Owner: igloo Type: merge| Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) |Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -+-- Changes (by simonpj): * owner: simonpj = igloo * type: bug = merge -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2004#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
Re: [GHC] #2004: Pattern matching against GADTs without -XGADTs has odd behavior.
#2004: Pattern matching against GADTs without -XGADTs has odd behavior.
-+--
Reporter: guest| Owner: simonpj
Type: bug | Status: new
Priority: normal | Milestone: 6.10 branch
Component: Compiler (Type checker) |Version: 6.8.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-+--
Comment (by simonpj):
Turns out that if `-XGADTs` was not set when pattern matching on a GADT,
we simply ignored the equational constraints. This is silly.
I've changed it so that `-XGADTs` is consulted only when deciding whether
to permit the ''definition'' of a GADT, not to permit its use. This is
consistent with (eg) overlapping instances.
Here's the note from TcPat
{{{
Note [Flags and equational constraints]
~~~
If there are equational constraints, we take account of them
regardless of flag settings; -XGADTs etc applies only to the
*definition* of a data type.
An alternative would be also to reject a program that *used*
constructors with equational constraints. But want we should avoid at
all costs is simply to *ignore* the constraints, since that gives
incomprehensible errors (Trac #2004).
}}}
Probably worth merging into the 6.8 branch, but not a big deal:
{{{
Fri Jan 4 12:58:14 GMT 2008 [EMAIL PROTECTED]
* Do not consult -XGADTs flag when pattern matching on GADTs
}}}
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2004#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] #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: closed
Priority: normal| Milestone: 6.8 branch
Component: Template Haskell |Version: 6.8.2
Severity: normal| Resolution: fixed
Keywords:| Difficulty: Unknown
Testcase: TH_import_loop| Architecture: Multiple
Os: Multiple |
--+-
Comment (by fons):
Replying to [comment:11 simonpj]:
Simon is right: B.hs depends on C.hs, which depends on A.hs-boot. I
think it's quite accidental that A happens to be compiled before B in your
curiously enough case, but after B in your original case.
All you need do is to make B depend on A, thus
{{{
{-# LANGUAGE TemplateHaskell #-}
module ModuleB where
import ModuleC
import ModuleA
$(nothing)
}}}
and it all works fine. Use -v to see the compilation order.
I finally managed to solve the problem turning around the circular
dependencies of my project (tranforming the SOURCE imports of the loop in
normal onces and vice versa). However, the workaround suggested by Simon
should work as you said.
Meanwhile I'll close the bug.
As far as I understand, ghc's dependency analysis could be improved
(otherwise a workaround would not be needed). I don't personally think
this bug should be closed and include it as a limitation in the docs
before considering simonmar's proposal, that is:
''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:12
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] #1509: Make unboxed tuples more supported
#1509: Make unboxed tuples more supported -+-- Reporter: guest| Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler |Version: 6.6.1 Severity: minor| Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -+-- Comment (by simonpj): Note: current unboxed tuples are eta-expanded by `CorePrep` since `Id.hasNoBinding` returns True. So we don't need to worry about generating curried versions of them. Nor would be possible to do so, since unboxed tuples can have unboxed components of varying width; they are not parametrically polymorphic. See also `Note [Primop wrappers]` in `Id.lhs`. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1509#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
Re: [GHC] #2016: GHC generates bad code for pointer manipulations from .cmm
#2016: GHC generates bad code for pointer manipulations from .cmm
--+-
Reporter: wb.kloke | Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
Component: Compiler |Version: 6.8.2
Severity: major | Resolution: duplicate
Keywords:| Difficulty: Unknown
Testcase:| Architecture: x86_64 (amd64)
Os: FreeBSD |
--+-
Changes (by simonmar):
* status: new = closed
* resolution: = duplicate
Comment:
I strongly suspect you are experiencing another symptom of #1989. The
code is compiled correctly for me:
{{{
~/builds/testing/rts make StgStdThunks.s HC=../compiler/stage2/ghc-
inplace
../compiler/stage2/ghc-inplace -Werror -H64m -Onot -fasm -optc-O2
-I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts
-static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -S
StgStdThunks.cmm -o StgStdThunks.s
~/builds/testing/rts head -50 StgStdThunks.s
.text
.align 8
.quad 0
.quad 34
.globl stg_sel_ret_0_upd_info
.type stg_sel_ret_0_upd_info, @object
stg_sel_ret_0_upd_info:
.Lcg:
movq %rbx,%rax
andq $-8,%rax
movq 8(%rax),%rbx
addq $8,%rbp
.Lc3:
testq $7,%rbx
jne .Lce
.Lcd:
movq (%rbx),%rax
movslq -8(%rax),%rcx
jmp *.Lnea(,%rcx,8)
.Lcb:
movq 8(%rbx),%rbx
jmp .Lc3
.Lca:
jmp *(%rbp)
.Lcc:
jmp *%rax
.Lce:
jmp *(%rbp)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2016#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)
Testcase: | Architecture: Multiple
Os: MacOS X |
-+--
Comment (by maeder):
Instead of modifying `hsc2hs` it is possible to add
{{{
--hsc2hs-options=-C -F$(HOME)/Library/Frameworks \
}}}
to libraries/Makefile (as line 246). I'll attach a patch that works on
other platforms, too.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1395#comment:28
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] #1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
#1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0 --+- Reporter: wb.kloke | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.8.3 Component: Compiler |Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: x86_64 (amd64) Os: FreeBSD | --+- Comment (by wb.kloke): This problem was caused by some code from the bootstrap compiler hibernating in the compat library. It seems advisable to rebuild compat after building compiler/stage1 with the new compiler if this is sufficiently different from the bootstrap compiler. This ticket may be either closed or changed to the request above. The error reported in #1620 was indeed caused by the same issue, as Simon Marlow correctly suggested. The perl script driver/ghc-asm.lprl has to be changed for FreeBSD-amd64 support. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1989#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
