Re: [GHC] #1150: Build Error on ia64
#1150: Build Error on ia64
--+-
Reporter: sim | Owner:
Type: bug | Status: reopened
Priority: normal| Milestone: _|_
Component: Build System |Version: 6.6
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Architecture: ia64
Os: Linux |
--+-
Changes (by sim):
* resolution: fixed =
* status: closed = reopened
Comment:
with gcc 3.3.6 and ghc-6.7.20070227-src.tar.bz2 i get the error:
{{{
../compiler/ghc-inplace -H16m -O -optc-O2 -optc-DNOSMP -static -I.
-#include HCIncludes.h -fvia-C -dcmm-lint -c Apply.cmm -o Apply.o
/tmp/ghc11738_0/ghc11738_0.s: Assembler messages:
/tmp/ghc11738_0/ghc11738_0.s:191:0:
Error: .endp outside of procedure
make[1]: *** [Apply.o] Error 1
make: *** [stage1] Error 1
}}}
Is there a chance to get the mangler work for gcc 3.3.6?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1150
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] #1171: GHC doesn't respect the imprecise exceptions semantics
Hi In response to Neil: why use `unsafePerformIO` rather than IO exceptions here? I think you're asking for more trouble... Are you referring to ioError? My knowledge of exceptions in Haskell is limited. The error architecture is often a long way from the IO monad, so whatever we do can't require the IO monad. Thanks Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: no location info when module name is omitted
On Tue, Feb 27, 2007 at 06:55:03PM +, Frederik Eaton wrote: If I try to compile a program which depends on a file which omits the module X where line, then I get an error message from ghc: no location info: file name does not match module name `Main' This is not very helpful, since it doesn't tell me which file the error is in, or what the error is. This is already fixed in the 6.6 branch and the HEAD, and thus should work in 6.6.1 and 6.8. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1141: Add extra completion functionality to readline package
#1141: Add extra completion functionality to readline package ---+ Reporter: judahj | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown| ---+ Comment (by igloo): I think we should require readline 5.0 so that the readline Cabal package always presents the same interface. If someone is stuck with readline 4 then we can always make a readline4 package. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1141 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] #1171: GHC doesn't respect the imprecise exceptions semantics
Neil Mitchell wrote: Hi In response to Neil: why use `unsafePerformIO` rather than IO exceptions here? I think you're asking for more trouble... Are you referring to ioError? My knowledge of exceptions in Haskell is limited. The error architecture is often a long way from the IO monad, so whatever we do can't require the IO monad. Yes - the example was in the IO monad so I thought you could use IO exceptions. In any case, I don't recommend using 'error' (or indeed 'unsafePerformIO') for errors you report to the user, purely because of its non-deterministic semantics. If you use a suitable error monad or IO exceptions, you can be sure that you'll get the same behaviour regardless of compiler or optimisation settings. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Compiler bug
Hi Paul,
On Sun, Jan 28, 2007 at 12:49:44PM +0300, Paul wrote:
Chasing modules from: hask1.hs
Compiling Main ( hask1.hs, hask1.o )
ghc-6.4: panic! (the `impossible' happened, GHC version 6.4):
ds_app_type Main.Tree{tc r16z} [a{tv a1a9}]
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
Thanks for the report. I think the problem is fixed in newer versions of
GHC (I've tried 6.4.2 and 6.6), which give the error
hask1.hs:24:1:
Class `Tree' used as a type
In the class declaration for `Tree'
when using data Node ... and
Multiple declarations of `Main.Tree'
Declared at: hask1.hs:12:5
hask1.hs:14:6
when using data Tree
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1110: Setting PATH needed in Windows Vista
#1110: Setting PATH needed in Windows Vista
-+--
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: high | Milestone: 6.6.1
Component: Driver |Version: 6.6
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86_64 (amd64)
Os: Windows |
-+--
Comment (by igloo):
OK, so your (cygwin) log looks like this:
{{{
D:\programas\ghc-6.6\gcc -BD:\programas\ghc-6.6\gcc-lib/ ...
...
cc1 -quiet ...
gcc: installation problem, cannot exec `cc1': No such file or directory
}}}
(the -B option tells gcc where to find its internal executables etc)
whereas mine looks like this:
{{{
c:\ghc\ghc-6.6\gcc -Bc:\ghc\ghc-6.6\gcc-lib/ ...
...
c:/ghc/ghc-6.6/gcc-lib/cc1.exe -quiet ...
...
}}}
Both claim to be `gcc version 3.4.5 (mingw special)`.
My guess is that on Vista gcc has decided that the -B directory we give it
doesn't exist, presumably because it's getting confused by directory
separators.
Is someone with Vista able to see if they can work out what we need to
pass please? You should be able to test with something like
{{{
c:/ghc/ghc-6.6/gcc q.c -o q -v -Bc:\\ghc\\ghc-6.6\\gcc-lib/
}}}
at a cygwin prompt (note the escaped '\'s), where q.c is just something
like
{{{
int main(void) {
return 0;
}
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1110
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] #1171: GHC doesn't respect the imprecise exceptions semantics
Hello, The code in YHC is roughly if some list is empty then error No files found else error Many files found. If this code were changed to the equivalent of error (if some list is empty then No files found else Many files found), would there still be circumstances where the actual output produced could vary? Thanks and best regards Thorkil On Wednesday 28 February 2007 12:31, Simon Marlow wrote: Neil Mitchell wrote: Hi In response to Neil: why use `unsafePerformIO` rather than IO exceptions here? I think you're asking for more trouble... Are you referring to ioError? My knowledge of exceptions in Haskell is limited. The error architecture is often a long way from the IO monad, so whatever we do can't require the IO monad. Yes - the example was in the IO monad so I thought you could use IO exceptions. In any case, I don't recommend using 'error' (or indeed 'unsafePerformIO') for errors you report to the user, purely because of its non-deterministic semantics. If you use a suitable error monad or IO exceptions, you can be sure that you'll get the same behaviour regardless of compiler or optimisation settings. Cheers, Simon ___ 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
[GHC] #1183: internal error: interpretBCO: unknown or unimplemented opcode 64956/64949
#1183: internal error: interpretBCO: unknown or unimplemented opcode 64956/64949 +--- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.2 Component: GHCi | Version: 6.6 Severity: normal |Keywords: Difficulty: Unknown |Testcase: Architecture: sparc| Os: Solaris +--- ''System information'' uname -a: SunOS tuck 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Fire-280R /etc/motd: Sun Microsystems Inc. SunOS 5.10 Generic January 2005 When running the supplied code in GHCi, it crashes out with the error message internal error: interpretBCO: unknown or unimplemented opcode 64956. The opcode seems to vary between 64956 and 64949, but possibly others. The crashing is consistent though. The code compiles and runs fine with GHC. It also runs fine on a Ubuntu linux system (albeit slow, which is to be expected) which I have access to. The code is taken from a university coursework assignment, and generates minimax labels for a tic-tac-toe game tree. It is a cutdown version of the full program, with only the code required to expose the bug present. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1183 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] #1183: internal error: interpretBCO: unknown or unimplemented opcode 64956/64949
#1183: internal error: interpretBCO: unknown or unimplemented opcode 64956/64949 -+-- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | -+-- Changes (by [EMAIL PROTECTED]): * milestone: 6.6.2 = Comment: Forgot the gcc version. From gcc -v: Reading specs from /opt/gnu/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/specs gcc version 2.95.2 19991024 (release) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1183 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] #1171: GHC doesn't respect the imprecise exceptions semantics
The code in YHC is roughly if some list is empty then error No files found else error Many files found. If this code were changed to the equivalent of error (if some list is empty then No files found else Many files found), would there still be circumstances where the actual output produced could vary? Maybe. If GHC knows that error is strict (which it might well do) then you could be back where you started. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1183: internal error: interpretBCO: unknown or unimplemented opcode 64956/64949
#1183: internal error: interpretBCO: unknown or unimplemented opcode 64956/64949 -+-- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi |Version: 6.6 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | -+-- Changes (by simonmar): * resolution: = duplicate * status: new = closed Comment: Thanks for the bug report - this one has been reported (several times!) before, though. See #1013. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1183 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] #1171: GHC doesn't respect the imprecise exceptions semantics
Simon Marlow wrote: The code in YHC is roughly if some list is empty then error No files found else error Many files found. If this code were changed to the equivalent of error (if some list is empty then No files found else Many files found), would there still be circumstances where the actual output produced could vary? Maybe. If GHC knows that error is strict (which it might well do) then you could be back where you started. Oops, error isn't strict, never mind. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1171: GHC doesn't respect the imprecise exceptions semantics
Simon Marlow wrote: Simon Marlow wrote: The code in YHC is roughly if some list is empty then error No files found else error Many files found. If this code were changed to the equivalent of error (if some list is empty then No files found else Many files found), would there still be circumstances where the actual output produced could vary? Maybe. If GHC knows that error is strict (which it might well do) then you could be back where you started. Oops, error isn't strict, never mind. Ok, so error *is* strict. Please ignore me, I have a cold and I'm having a bad day :-( Cheers, Simon ___ 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) Testcase: | Architecture: Unknown Os: Unknown| ---+ Changes (by igloo): * milestone: 6.6.1 = Not GHC Comment: Taking this off the 6.6.1 milestone as it isn't something we can fix in the source; in order to haddock the Win32 package on Linux we'd need to be able to hsc2hs Control.hsc, which we can't do. I think we'll just have to include in the release process steps to merge in the results of haddocking Win32 by hand. -- 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] #406: internal error: EVACUATED object entered!
#406: internal error: EVACUATED object entered! -+-- Reporter: malaire | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: None |Version: 6.4 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -+-- Changes (by simonmar): * resolution: = worksforme * status: reopened = closed Comment: Tried to reproduce without success using GHC 6.6. I downloaded the exact revision of Pugs (4916), and fixed up a few things in the source to make it compile with 6.6. The oo/destruction tests appear to pass without failure. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/406 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] #1157: hxt cannot be compiled with optimization level 2 (-O2)
#1157: hxt cannot be compiled with optimization level 2 (-O2) ---+ Reporter: [EMAIL PROTECTED] | Owner: Type: bug| Status: closed Priority: normal | Milestone: 6.6.1 Component: libraries (other) |Version: 6.6 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X| ---+ Changes (by igloo): * resolution: = invalid * status: new = closed Comment: This looks like an internal compiler error from gcc. The web has similar reports that it claims are fixed in gcc 3.3.1, so upgrading may fix the problem. If not, you'll have to file a bug against gcc. Thanks Ian -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1157 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] #1157: hxt cannot be compiled with optimization level 2 (-O2)
Could it be documented at: http://www.haskell.org/ghc/download_ghc_66.html#macosxppc that at least gcc 3.3.1 is required GHC schrieb: #1157: hxt cannot be compiled with optimization level 2 (-O2) ---+ Reporter: [EMAIL PROTECTED] | Owner: Type: bug| Status: closed Priority: normal | Milestone: 6.6.1 Component: libraries (other) |Version: 6.6 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X| ---+ Changes (by igloo): * resolution: = invalid * status: new = closed Comment: This looks like an internal compiler error from gcc. The web has similar reports that it claims are fixed in gcc 3.3.1, so upgrading may fix the problem. If not, you'll have to file a bug against gcc. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #249: -caf-all bugs
#249: -caf-all bugs
-+--
Reporter: simonmar | Owner: igloo
Type: merge| Status: new
Priority: low | Milestone: 6.6.1
Component: Profiling|Version: 6.2.1
Severity: normal | Resolution: None
Keywords: | Difficulty: Unknown
Testcase: prof001 prof002 | Architecture: Unknown
Os: Unknown |
-+--
Changes (by simonmar):
* status: assigned = new
* owner: simonmar = igloo
* type: bug = merge
Comment:
Now fixed. To merge:
{{{
Wed Feb 28 07:50:09 PST 2007 Simon Marlow [EMAIL PROTECTED]
* Fix #249 (-caf-all bugs)
}}}
and in the testsuite:
{{{
Wed Feb 28 15:51:29 GMT 2007 Simon Marlow [EMAIL PROTECTED]
* prof001 prof002 are not broken now
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/249
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] #1180: ghci 6.7 PPC memory corruption
#1180: ghci 6.7 PPC memory corruption
-+--
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: GHCi |Version: 6.7
Severity: normal | Resolution: invalid
Keywords: | Difficulty: Unknown
Testcase: | Architecture: powerpc
Os: MacOS X |
-+--
Changes (by thorkilnaur):
* resolution: = invalid
* status: new = closed
Comment:
Thanks a lot for this report. This seems to be caused by the patch merge
error for which a patch was applied on 2007-Jan-28. See
http://www.haskell.org/pipermail/glasgow-haskell-users/2007-
January/011920.html. I can find the patch applied to a recently pulled ghc
HEAD:
{{{
Sun Jan 28 22:32:16 CET 2007 Ian Lynagh [EMAIL PROTECTED]
* Fix GHCi on PowerPC OS X
David Kirkman and Peter Tanski noticed that a line had been removed
during
a patch merge which meant that oc-image pointed to the wrong place and
ultimately caused an error from realloc.
}}}
So I am closing this bug report. Please feel free to reopen if you cannot
make this problem go away.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1180
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] #1077: documentation error and omission
#1077: documentation error and omission ---+ Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Documentation |Version: 6.6 Severity: trivial| Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Multiple | ---+ Changes (by simonmar): * priority: low = normal * owner: = igloo * type: bug = merge Comment: Fixed; the building guide is now on the wiki and doesn't have these bugs. I've just updated the main GHC documentation wiki page so that we don't advertise the old building guide any more. We need to merge the removal of the old building guide into the 6.6 branch, so I've left this ticket as a merge. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1077 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] #1184: Hasktags misses symbol
#1184: Hasktags misses symbol +--- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 6.6 Severity: normal |Keywords: Difficulty: Unknown |Testcase: Architecture: Unknown | Os: Windows +--- (not sure I filed this bug appropriately. I belive hasktags came as part of the ghc-6.6 binary package. Please advise if there's a better place) Hasktags is missing an obvious symbol. $ darcs get --partial http://happs.org/HAppS $ cd HAppS/src $ hasktags -c `find . -name '*.hs' |grep -v _darcs` $ grep boolM# - not found $ grep boolM `find . -name '*.hs' |grep -v _darcs` # - found -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/1184 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
