Re: [GHC] #2739: GHC API crashes on template haskell splices
#2739: GHC API crashes on template haskell splices -+-- Reporter: waern |Owner: nominolo Type: bug | Status: assigned Priority: normal|Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by spl): * cc: leat...@cs.uu.nl (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2739#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] #2692: ghc-6.10.0.20081007 seg faults on Sparc
#2692: ghc-6.10.0.20081007 seg faults on Sparc -+-- Reporter: maeder|Owner: benl Type: bug | Status: assigned Priority: normal|Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Solaris Architecture: sparc | -+-- Comment (by maeder): Wrt my binary-dist I forgot to mention that it was compiled with gcc-4.2.2, but I was able to use it with gcc-3.4.4 after removing `-fno- toplevel-reorder` from `extra-gcc-opts` Under linux and macs there are `-mno-omit-leaf-frame-pointer -fno-unit- at-a-time` in `extra-gcc-opts`. May the lack of any of these options be responsible for the long compilation times observed with gcc-4.2.x #2906? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2692#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] #2692: ghc-6.10.0.20081007 seg faults on Sparc
#2692: ghc-6.10.0.20081007 seg faults on Sparc -+-- Reporter: maeder|Owner: benl Type: bug | Status: assigned Priority: normal|Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Solaris Architecture: sparc | -+-- Comment (by maeder): This ticket can be closed, as the patch fixed it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2692#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] #2285: Solaris 9 build fails at stage2 with undefined symbol errors (for libm symbols)
#2285: Solaris 9 build fails at stage2 with undefined symbol errors (for libm symbols) --+- Reporter: TimBishop |Owner: Type: bug| Status: new Priority: normal |Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | --+- Comment (by maeder): Sorry, I noticed this ticket only recently. It looks to me that libm.so points to libm.so.1, but libm.so.2 is needed for (dynamic) linking. At least I had similar link errors with libm.so being libm.so.1. I have no idea why you could finally link in a static libm.a and still have a reference to libm.so. What version of libm does `ldd` of your binary show? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2285#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
seg-fault in 6.10.1
Dear GHC team, I `make' my (large) project in ghc-6.10.1, Linux Debian, i386-unknown, run the executable, and obtain Segmentation fault. Then, I noted that in a few places the compiler warned about skipping some class member implementations in some instances. I added these implementations, and now it works correct. Are you interested in the bug report on the above part of Segmentation fault ? - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #2975: GHCi's :edit command calls the editor with stdin in nonblocking mode
#2975: GHCi's :edit command calls the editor with stdin in nonblocking mode
-+--
Reporter: kaol | Owner:
Type: bug | Status: new
Priority: normal| Component: GHCi
Version: 6.10.1| Severity: normal
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
When using editline support, GHCi sets stdin to nonblocking mode.
{{{
withReadline = bracket_ stopTimer (do startTimer; setNonBlockingFD 0
-- Two problems are being worked around here:
-- 1. readline sometimes puts stdin into blocking mode,
--so we need to put it back for the IO library
}}}
Most editors expect that stdin is in blocking mode and nothing in the code
sets the mode that way and the editor inherits the mode via {{{system}}}
call in {{{editFile}}}, when using {{{:edit}}}.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2975
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] #2971: readFile /proc/mounts hangs on an amd64 machine
#2971: readFile /proc/mounts hangs on an amd64 machine --+- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.10.1 Severity: critical | Resolution: Keywords:| Testcase: Os: Linux | Architecture: Unknown/Multiple --+- Comment (by rm): SBCL ran into this problem some time ago. It turned out the Linux kernel doesn't support standard select semantics on files in procfs and sysfs: http://bugzilla.kernel.org/show_bug.cgi?id=11014 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2971#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] #2976: :show bindings give wrong results when a variable was redefined
#2976: :show bindings give wrong results when a variable was redefined
-+--
Reporter: phercek | Owner:
Type: bug | Status: new
Priority: normal| Component: GHCi
Version: 6.10.1| Severity: normal
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
Bindings displayed with '':show bindings'' do not correspond to what can
be observed by printing values explicitly for example by using '':force''.
The differences happen when a variable is redefined.[[BR]]
I saw the bug in 6.10.1, and 6.8.2. Pepe Iborra could reproduce it in
6.8.1 and noticed that it works well in 6.6.
Notice the value and type reported for variable ''test'' after it has been
redefined in this example.
{{{
% ghci
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude let test = 0
Prelude :show bindings
test :: Integer = _
Prelude :force test
test = 0
Prelude let test = zero
Prelude :show bindings
test :: Integer = 0
Prelude :force test
test = ['z','e','r','o']
Prelude :quit
Leaving GHCi.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2976
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] #2976: :show bindings give wrong results when a variable was redefined
#2976: :show bindings give wrong results when a variable was redefined --+- Reporter: phercek | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: GHCi |Version: 6.10.1 Severity: normal| Resolution: Keywords:| Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --+- Changes (by mnislaih): * cc: mnisl...@gmail.com (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2976#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: seg-fault in 6.10.1
Serge D. Mechveliani wrote: Dear GHC team, let me answer as a plain ghc user. I `make' my (large) project in ghc-6.10.1, Linux Debian, i386-unknown, run the executable, and obtain Segmentation fault. Then, I noted that in a few places the compiler warned about skipping some class member implementations in some instances. I added these implementations, and now it works correct. Segmentation fault should not result from missing method definitions. So please report a bug if it can be reproduced. Cheers Christian Are you interested in the bug report on the above part of Segmentation fault ? - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2951: Add support for amd64-solaris2 platform
#2951: Add support for amd64-solaris2 platform +--- Reporter: kgardas |Owner: simonmar Type: feature request | Status: new Priority: normal |Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | +--- Comment (by simonmar): The platform test in `config.guess` doesn't pass any `-m64` options to gcc, all it does is test whether `__amd64` is defined. So doesn't that mean that the C compiler on your platform is generating 64-bit objects by default? I am still confused. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2951#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] #2964: System.Directory.getCurrentDirectory doesn't work on win32 if the current directory has non-ascii characters in its name
#2964: System.Directory.getCurrentDirectory doesn't work on win32 if the current directory has non-ascii characters in its name +--- Reporter: kirby|Owner: Type: bug | Status: closed Priority: normal |Milestone: Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | +--- Changes (by simonmar): * status: new = closed * difficulty: = Unknown * resolution: = duplicate Comment: looks like the same bug as #2963 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2964#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] #2951: Add support for amd64-solaris2 platform
#2951: Add support for amd64-solaris2 platform
+---
Reporter: kgardas |Owner: simonmar
Type: feature request | Status: new
Priority: normal |Milestone: 6.12 branch
Component: Compiler | Version: 6.10.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Solaris
Architecture: x86_64 (amd64) |
+---
Comment (by kgardas):
Not at all! GCC by default generates 32bit code:
{{{
ka...@silence:/tmp$ cat hello.c
int
main()
{
return 0;
}
ka...@silence:/tmp$ gcc -o hello hello.c
ka...@silence:/tmp$ file hello
hello: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically
linked, not stripped, no debugging information available
ka...@silence:/tmp$
}}}
In addition this define is not defined by default, but when you use -m64
option. Then it's used. BTW: I'm also a little bit confused by the fact
that when I invoke config.guess from the command-line it claims it's
running on i386-pc-solaris, but if I run ./configure then it shows x86_64
-unknown-solaris...
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2951#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] #2753: GHC 6.10.1 cannot compile Crypto-4.1.0
#2753: GHC 6.10.1 cannot compile Crypto-4.1.0 -+-- Reporter: thoughtpolice |Owner: Type: bug | Status: new Priority: normal|Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by awick): * cc: awick (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2753#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] #2946: tracing should be controled by a global flag (it should not be resume context specific)
#2946: tracing should be controled by a global flag (it should not be resume context specific) --+- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal| Milestone: Component: GHCi |Version: 6.10.1 Severity: minor | Resolution: Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --+- Comment (by phercek): Current :steplocal fills in trace history with all source locations executed even when they are not inside the function stepped through using :steplocal. If this is accepted then the source locations outside the localy stepped function should not be logged to trace history if trace is not set to True. Actually I think the locations ouside the locally stepped function should not be added to the trace history even when this is rejected in general. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2946#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: seg-fault in 6.10.1
Yes we are. If you aren't using the FFI or unsafe things, you should not get a seg fault. Do help us to reproduce it -- thanks. Simon | -Original Message- | From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs- | boun...@haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 23 January 2009 13:59 | To: glasgow-haskell-bugs@haskell.org | Cc: glasgow-haskell-us...@haskell.org | Subject: seg-fault in 6.10.1 | | Dear GHC team, | | I `make' my (large) project in ghc-6.10.1, Linux Debian, i386-unknown, | run the executable, and obtain | | Segmentation fault. | | Then, I noted that in a few places the compiler warned about skipping | some class member implementations in some instances. | I added these implementations, and now it works correct. | | Are you interested in the bug report on the above part of | Segmentation fault ? | | - | Serge Mechveliani | mech...@botik.ru | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
