Re: [GHC] #2722: loop when compiling with -O option with ghc-6.10.0.20081019
#2722: loop when compiling with -O option with ghc-6.10.0.20081019 -+-- Reporter: uwe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: libraries (other) |Version: 7.0.1 Resolution: invalid | Keywords: arrows Testcase: tyepcheck/should_run/T2722 | Blockedby: Difficulty: Unknown | Os: Linux Blocking: | Architecture: x86_64 (amd64) Failure: Runtime crash | -+-- Changes (by igloo): * status: new = closed * resolution: = invalid Comment: Ah, you mean there is no bug in the arrow library after all? OK, thanks for looking into it and letting us know; I'll close this ticket again then. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2722#comment:24 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] #4996: can't link executables due to dtrace error on Mac OS X 10.5
#4996: can't link executables due to dtrace error on Mac OS X 10.5
-+--
Reporter: MtnViewMark | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.0.2 |Keywords: dtrace osx mac 10.5
Testcase:| Blockedby:
Os: MacOS X |Blocking:
Architecture: Unknown/Multiple | Failure: GHC doesn't work at all
-+--
When building an executable on 10.5, the link step fails. Problem occurs
with 7.0.2 i386 and x86_64 builds of 7.0.2 on Mac OS X 10.5. Same
compilers work find on 10.6.
Example log from building HsColour:
Linking dist/build/HsColour/HsColour ...
error: Could not compile reconstructed dtrace script:
Unhandled typedefs encoding version v2
provider HaskellEvent {
probe startup(EventCapNo);
probe gc__work(EventCapNo);
probe gc(int, double, long,...)(EventCapNo);
probe gc__done(EventCapNo);
probe thread_wakeup(EventCapNo,EventThreadID,EventCapNo);
probe thread__runnable(EventCapNo,EventThreadID);
probe migrate__thread(EventCapNo,EventThreadID,EventCapNo);
probe create__thread(EventCapNo,EventThreadID);
probe gc__start(EventCapNo);
probe gc__end(EventCapNo);
probe stop__thread(EventCapNo,EventThreadID,EventThreadStatus);
probe run__thread(EventCapNo,EventThreadID);
probe user__msg(EventCapNo,char *);
};
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent
provider
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent module
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent
function
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent name
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent args
ld: error creating dtrace DOF section
collect2: ld returned 1 exit status
cabal: Error: some packages failed to install:
hscolour-1.17 failed during the building phase. The exception was:
ExitFailure 1
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4996
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] #4984: OS X: ld: warning: -read_only_relocs cannot be used with x86_64
#4984: OS X: ld: warning: -read_only_relocs cannot be used with x86_64 ---+ Reporter: igloo |Owner: Type: bug | Status: new Priority: high|Milestone: 7.2.1 Component: Compiler| Version: 7.0.2 Keywords: | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: None/Unknown ---+ Changes (by carter): * version: 7.0.1 = 7.0.2 * os: Unknown/Multiple = MacOS X * architecture: Unknown/Multiple = x86_64 (amd64) Comment: I've seen this error a bunch, but at least in all the haskell-only code i've used works fine as such. but would it affect how code that links to c/cpp libraries works? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4984#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
[GHC] #4997: Mac installers are missing ghc cabal guides
#4997: Mac installers are missing ghc cabal guides -+-- Reporter: MtnViewMark | Owner: Type: bug | Status: new Priority: normal| Component: None Version: 7.0.2 |Keywords: Testcase:| Blockedby: Os: MacOS X |Blocking: Architecture: Unknown/Multiple | Failure: Installing GHC failed -+-- The The GHC User's Guide the Cabal guide are missing. They should be in /Library/Frameworks /GHC.framework/Versions/7.0.2-i386 /usr/share/doc/ghc/html /users_guide /Cabal -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4997 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] #4905: New flag to disable warning on incomplete pattern matches in lambdas
#4905: New flag to disable warning on incomplete pattern matches in lambdas --+- Reporter: batterseapower | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.0.1 Resolution: fixed| Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by igloo): * status: merge = closed Comment: 7.0 branch is closed, and this is already in the HEAD (which will become the 7.2 branch), so closing this ticket. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4905#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] #4956: threadDelay behavior 64-bit mac os x
#4956: threadDelay behavior 64-bit mac os x
---+
Reporter: perikov |Owner:
Type: bug | Status: new
Priority: normal |Milestone:
Component: Compiler| Version: 7.0.1
Keywords: threadDelay | Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime
---+
Description changed by igloo:
Old description:
threadDelay 100
works as expected in 7.0.1-x86_64
return immediately in DEVELOPMENT 7.1.20110131
hangs eating CPU in STABLE 7.0.1.20110201, 7.0.1.20110211
to reproduce:
fire up ghci
import Control.Concurrent
threadDelay 100
New description:
threadDelay 100
{{{
works as expected in 7.0.1-x86_64
return immediately in DEVELOPMENT 7.1.20110131
hangs eating CPU in STABLE 7.0.1.20110201, 7.0.1.20110211
}}}
to reproduce:
fire up ghci
{{{
import Control.Concurrent
threadDelay 100
}}}
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4956#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
[GHC] #4998: Car Games - How to Design Car Games for Kids
#4998: Car Games - How to Design Car Games for Kids +--- Reporter: fungames | Owner: michelle smith Type: feature request | Status: new Priority: normal | Component: Compiler (Parser) Version: 7.0.2|Keywords: Car Games Testcase: | Blockedby: Os: MacOS X |Blocking: Architecture: powerpc64| Failure: None/Unknown +--- [[Image(http://www.broombroom.com/images/CarGames1.gif)]] One of the biggest challenge that a parent undergoes is how to keep the child entertained during the long hours of road trip. Well, the answer to your woes can be as simple as '''[http://blackpenguin.net/ Fun Games]'''. You may not be aware of this but having the right '''car games''' to offer to your child during the grueling hours of the road trip can make all the difference in the world. There are plenty of '''Racing Games''' options that you can choose from the world wide web so this should not prove to be a big problem. [[Image(http://free-online-games-free.com/Menu/Racing%20Pics/driving- test.jpg)]] However, if you want to make your own custom made '''[http://blackpenguin.net/ Fun Games]''' for your kid to play would not be a problem also. To get started in making your own '''joke games''', it is best that you write down all that ideas that you have regarding the '''interesting game'''. That way, you can clearly see the pros and cons of your every game idea. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4998 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] #4956: threadDelay behavior 64-bit mac os x
#4956: threadDelay behavior 64-bit mac os x
---+
Reporter: perikov |Owner:
Type: bug | Status: infoneeded
Priority: normal |Milestone: 7.2.1
Component: Compiler| Version: 7.0.1
Keywords: threadDelay | Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime
---+
Changes (by igloo):
* status: new = infoneeded
* milestone: = 7.2.1
Comment:
Can you still reproduce this? It seems to be working fine for me in 7.0.2
and HEAD:
{{{
Prelude Control.Concurrent Data.Time.Clock.POSIX do getPOSIXTime =
print; threadDelay 100; getPOSIXTime = print
1299355338.201281s
1299355339.201907s
}}}
{{{
Prelude Control.Concurrent Data.Time.Clock.POSIX do getPOSIXTime =
print; threadDelay 100; getPOSIXTime = print
1299355440.355244s
1299355441.355901s
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4956#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] #4959: Warning about variables with leading underscore that are used anyway
#4959: Warning about variables with leading underscore that are used anyway ---+ Reporter: Lemming |Owner: Type: feature request | Status: new Priority: normal |Milestone: 7.4.1 Component: Compiler (Parser) | Version: 7.0.1 Keywords: warning unused underscore variable | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple| Blocking: Architecture: Unknown/Multiple| Failure: None/Unknown ---+ Changes (by igloo): * milestone: = 7.4.1 Comment: Thanks for the suggestion. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4959#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] #4960: Better inlining test in CoreUnfold
#4960: Better inlining test in CoreUnfold -+-- Reporter: simonpj |Owner: Type: bug | Status: new Priority: normal|Milestone: 7.4.1 Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by igloo): * milestone: = 7.4.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4960#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] #4962: Dead code fed to CorePrep because RULEs keep it alive spuriously
#4962: Dead code fed to CorePrep because RULEs keep it alive spuriously -+-- Reporter: batterseapower|Owner: Type: bug | Status: patch Priority: normal|Milestone: 7.2.1 Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Changes (by igloo): * status: new = patch * milestone: = 7.2.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4962#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] #4965: 60% performance regression in continuation-heavy code between 6.12 and 7
#4965: 60% performance regression in continuation-heavy code between 6.12 and 7 -+-- Reporter: bos |Owner: Type: bug | Status: new Priority: high |Milestone: 7.2.1 Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Changes (by igloo): * priority: normal = high * milestone: = 7.2.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4965#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] #4967: internal error: stg_ap_v_ret on forkProcess + executeFile
#4967: internal error: stg_ap_v_ret on forkProcess + executeFile -+-- Reporter: udoprog |Owner: Type: bug | Status: infoneeded Priority: normal|Milestone: 7.2.1 Component: Compiler | Version: 6.12.1 Keywords: forkProcess stg_ap_v_ret | Testcase: Blockedby:| Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64)| Failure: None/Unknown -+-- Changes (by igloo): * status: new = infoneeded * milestone: = 7.2.1 Comment: I'm a little confused: Can you reproduce this problem? If so, if you are able to remove dependencies on other packages (e.g. does it still happen if you just print messages, rather than using hsyslog?), that would make it easier for us to look into. If it only happened once, then there's not much we can do without a way to reproduce it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4967#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] #4968: openTempFile fails on Windows if a directory exists with the file name it tries
#4968: openTempFile fails on Windows if a directory exists with the file name it tries ---+ Reporter: ganesh |Owner: Type: bug | Status: new Priority: high|Milestone: 7.2.1 Component: libraries/base | Version: 7.0.1 Keywords: | Testcase: Blockedby: | Difficulty: Os: Windows | Blocking: Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime ---+ Changes (by igloo): * priority: normal = high * milestone: = 7.2.1 Comment: Thanks for the report. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4968#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] #4970: time002 and time004 (ghci) test failures on OS X 64 bit
#4970: time002 and time004 (ghci) test failures on OS X 64 bit ---+ Reporter: gwright |Owner: gwright Type: bug | Status: patch Priority: normal |Milestone: 7.2.1 Component: GHCi| Version: 7.0.1 Keywords: | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime ---+ Changes (by igloo): * milestone: = 7.2.1 Comment: Great stuff, thanks Greg! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4970#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] #4971: All essential C-- transformations in new codegen should have infinite optimization fuel
#4971: All essential C-- transformations in new codegen should have infinite optimization fuel -+-- Reporter: ezyang|Owner: Type: bug | Status: new Priority: high |Milestone: 7.4.1 Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by igloo): * priority: normal = high * milestone: = 7.4.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4971#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] #4976: zipWith static argument transformation
#4976: zipWith static argument transformation --+- Reporter: aristidb | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base |Version: 7.0.1 Resolution: wontfix | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by igloo): * status: new = closed * resolution: = wontfix Comment: In the absence of evidence that it's a net gain, I'll close this ticket. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4976#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] #4977: Warning about unqualified implicit imports
#4977: Warning about unqualified implicit imports -+-- Reporter: Lemming |Owner: Type: feature request | Status: new Priority: highest |Milestone: 7.2.1 Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by igloo): * priority: normal = highest * milestone: = 7.2.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4977#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] #4980: Warning about module abbreviation clashes
#4980: Warning about module abbreviation clashes -+-- Reporter: Lemming |Owner: Type: feature request | Status: new Priority: normal|Milestone: 7.4.1 Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by igloo): * milestone: = 7.4.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4980#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] #4981: inconsistent class requirements with TypeFamilies and FlexibleContexts
#4981: inconsistent class requirements with TypeFamilies and FlexibleContexts +--- Reporter: ganesh |Owner: Type: bug | Status: new Priority: high |Milestone: 7.2.1 Component: Compiler (Type checker) | Version: 7.0.1 Keywords: | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: GHC rejects valid program +--- Changes (by igloo): * priority: normal = high * milestone: = 7.2.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4981#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] #4987: darcs: internal error: stg_ap_v_ret (GHC version 7.0.1 for x86_64_apple_darwin)
#4987: darcs: internal error: stg_ap_v_ret (GHC version 7.0.1 for
x86_64_apple_darwin)
---+
Reporter: guest |Owner:
Type: bug | Status: new
Priority: normal |Milestone:
Component: Compiler| Version: 7.0.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86_64 (amd64) | Failure: Runtime crash
---+
Description changed by igloo:
Old description:
While doing a darcs pull from the Agda repository
http://www.cse.chalmers.se/~nad/repos/Agda I got:
darcs: internal error: stg_ap_v_ret
(GHC version 7.0.1 for x86_64_apple_darwin)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
This happened just once.
darcs version 2.5.1
GHC was bootstrapped using the x86_64 ghc-6.10.4 from MacPorts
Mac OS X 10.6.6 (Snow Leopard)
Unsure of relevant Xcode version as neither ghc-6.10.4 nor ghc-7.0.1
built recently, but current.
New description:
While doing a darcs pull from the Agda repository
http://www.cse.chalmers.se/~nad/repos/Agda I got:
{{{
darcs: internal error: stg_ap_v_ret
(GHC version 7.0.1 for x86_64_apple_darwin)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
}}}
This happened just once.
{{{
darcs version 2.5.1
GHC was bootstrapped using the x86_64 ghc-6.10.4 from MacPorts
Mac OS X 10.6.6 (Snow Leopard)
Unsure of relevant Xcode version as neither ghc-6.10.4 nor ghc-7.0.1 built
recently, but current.
}}}
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4987#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] #4987: darcs: internal error: stg_ap_v_ret (GHC version 7.0.1 for x86_64_apple_darwin)
#4987: darcs: internal error: stg_ap_v_ret (GHC version 7.0.1 for x86_64_apple_darwin) ---+ Reporter: guest |Owner: Type: bug | Status: infoneeded Priority: normal |Milestone: 7.2.1 Component: Compiler| Version: 7.0.1 Keywords: | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: Runtime crash ---+ Changes (by igloo): * status: new = infoneeded * milestone: = 7.2.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4987#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] #4995: Compiling pandoc with llvm backend fails with panic
#4995: Compiling pandoc with llvm backend fails with panic
+---
Reporter: jgm |Owner: dterei
Type: bug | Status: new
Priority: normal |Milestone:
Component: Compiler (LLVM) | Version: 7.0.2
Keywords: llvm pandoc | Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86 | Failure: None/Unknown
+---
Description changed by igloo:
Old description:
I decided to try compiling pandoc with the llvm backend (GHC 7.0.2 32 bit
on Mac OSX 10.6). I put -fllvm in Ghc-Options in the cabal file and did
a 'cabal install'.
It failed eventually with the following message, which I am duly
reporting:
[14 of 37] Compiling Text.Pandoc.Readers.LaTeX (
src/Text/Pandoc/Readers/LaTeX.hs, dist/build/pandoc/pandoc-
tmp/Text/Pandoc/Readers/LaTeX.o )
SpecConstr
Function `$w$j{v s62TR} [lid]'
has two call patterns, but the limit is 1
Use -fspec-constr-count=n to set the bound
Use -dppr-debug to see specialisations
SpecConstr
Function `$w$j{v s62TR} [lid]'
has two call patterns, but the limit is 1
Use -fspec-constr-count=n to set the bound
Use -dppr-debug to see specialisations
[...deleted more in that vein...]
SpecConstr
Function `$w$j{v s63cF} [lid]'
has two call patterns, but the limit is 1
Use -fspec-constr-count=n to set the bound
Use -dppr-debug to see specialisations
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.2 for i386-apple-darwin):
LLvmMangler Cannot read_c6as it's not an Int
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
New description:
I decided to try compiling pandoc with the llvm backend (GHC 7.0.2 32 bit
on Mac OSX 10.6). I put -fllvm in Ghc-Options in the cabal file and did a
'cabal install'.
It failed eventually with the following message, which I am duly
reporting:
{{{
[14 of 37] Compiling Text.Pandoc.Readers.LaTeX (
src/Text/Pandoc/Readers/LaTeX.hs, dist/build/pandoc/pandoc-
tmp/Text/Pandoc/Readers/LaTeX.o )
SpecConstr
Function `$w$j{v s62TR} [lid]'
has two call patterns, but the limit is 1
Use -fspec-constr-count=n to set the bound
Use -dppr-debug to see specialisations
SpecConstr
Function `$w$j{v s62TR} [lid]'
has two call patterns, but the limit is 1
Use -fspec-constr-count=n to set the bound
Use -dppr-debug to see specialisations
[...deleted more in that vein...]
SpecConstr
Function `$w$j{v s63cF} [lid]'
has two call patterns, but the limit is 1
Use -fspec-constr-count=n to set the bound
Use -dppr-debug to see specialisations
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.2 for i386-apple-darwin):
LLvmMangler Cannot read_c6as it's not an Int
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4995#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] #4995: Compiling pandoc with llvm backend fails with panic
#4995: Compiling pandoc with llvm backend fails with panic +--- Reporter: jgm |Owner: dterei Type: bug | Status: new Priority: normal |Milestone: 7.2.1 Component: Compiler (LLVM) | Version: 7.0.2 Keywords: llvm pandoc | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86 | Failure: None/Unknown +--- Changes (by igloo): * milestone: = 7.2.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4995#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] #4996: can't link executables due to dtrace error on Mac OS X 10.5
#4996: can't link executables due to dtrace error on Mac OS X 10.5
+---
Reporter: MtnViewMark |Owner:
Type: bug | Status: new
Priority: normal |Milestone:
Component: Compiler | Version: 7.0.2
Keywords: dtrace osx mac 10.5 | Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: Unknown/Multiple | Failure: GHC doesn't work at all
+---
Description changed by igloo:
Old description:
When building an executable on 10.5, the link step fails. Problem occurs
with 7.0.2 i386 and x86_64 builds of 7.0.2 on Mac OS X 10.5. Same
compilers work find on 10.6.
Example log from building HsColour:
Linking dist/build/HsColour/HsColour ...
error: Could not compile reconstructed dtrace script:
Unhandled typedefs encoding version v2
provider HaskellEvent {
probe startup(EventCapNo);
probe gc__work(EventCapNo);
probe gc(int, double, long,...)(EventCapNo);
probe gc__done(EventCapNo);
probe thread_wakeup(EventCapNo,EventThreadID,EventCapNo);
probe thread__runnable(EventCapNo,EventThreadID);
probe migrate__thread(EventCapNo,EventThreadID,EventCapNo);
probe create__thread(EventCapNo,EventThreadID);
probe gc__start(EventCapNo);
probe gc__end(EventCapNo);
probe stop__thread(EventCapNo,EventThreadID,EventThreadStatus);
probe run__thread(EventCapNo,EventThreadID);
probe user__msg(EventCapNo,char *);
};
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent
provider
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent module
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent
function
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent name
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent args
ld: error creating dtrace DOF section
collect2: ld returned 1 exit status
cabal: Error: some packages failed to install:
hscolour-1.17 failed during the building phase. The exception was:
ExitFailure 1
New description:
When building an executable on 10.5, the link step fails. Problem occurs
with 7.0.2 i386 and x86_64 builds of 7.0.2 on Mac OS X 10.5. Same
compilers work find on 10.6.
Example log from building HsColour:
{{{
Linking dist/build/HsColour/HsColour ...
error: Could not compile reconstructed dtrace script:
Unhandled typedefs encoding version v2
provider HaskellEvent {
probe startup(EventCapNo);
probe gc__work(EventCapNo);
probe gc(int, double, long,...)(EventCapNo);
probe gc__done(EventCapNo);
probe thread_wakeup(EventCapNo,EventThreadID,EventCapNo);
probe thread__runnable(EventCapNo,EventThreadID);
probe migrate__thread(EventCapNo,EventThreadID,EventCapNo);
probe create__thread(EventCapNo,EventThreadID);
probe gc__start(EventCapNo);
probe gc__end(EventCapNo);
probe stop__thread(EventCapNo,EventThreadID,EventThreadStatus);
probe run__thread(EventCapNo,EventThreadID);
probe user__msg(EventCapNo,char *);
};
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent
provider
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent module
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent
function
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent name
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent args
ld: error creating dtrace DOF section
collect2: ld returned 1 exit status
cabal: Error: some packages failed to install:
hscolour-1.17 failed during the building phase. The exception was:
ExitFailure 1
}}}
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4996#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] #4996: can't link executables due to dtrace error on Mac OS X 10.5
#4996: can't link executables due to dtrace error on Mac OS X 10.5
+---
Reporter: MtnViewMark |Owner:
Type: bug | Status: new
Priority: normal |Milestone:
Component: Compiler | Version: 7.0.2
Keywords: dtrace osx mac 10.5 | Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: Unknown/Multiple | Failure: GHC doesn't work at all
+---
Description changed by igloo:
Old description:
When building an executable on 10.5, the link step fails. Problem occurs
with 7.0.2 i386 and x86_64 builds of 7.0.2 on Mac OS X 10.5. Same
compilers work find on 10.6.
Example log from building HsColour:
{{{
Linking dist/build/HsColour/HsColour ...
error: Could not compile reconstructed dtrace script:
Unhandled typedefs encoding version v2
provider HaskellEvent {
probe startup(EventCapNo);
probe gc__work(EventCapNo);
probe gc(int, double, long,...)(EventCapNo);
probe gc__done(EventCapNo);
probe thread_wakeup(EventCapNo,EventThreadID,EventCapNo);
probe thread__runnable(EventCapNo,EventThreadID);
probe migrate__thread(EventCapNo,EventThreadID,EventCapNo);
probe create__thread(EventCapNo,EventThreadID);
probe gc__start(EventCapNo);
probe gc__end(EventCapNo);
probe stop__thread(EventCapNo,EventThreadID,EventThreadStatus);
probe run__thread(EventCapNo,EventThreadID);
probe user__msg(EventCapNo,char *);
};
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent
provider
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent module
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent
function
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent name
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent args
ld: error creating dtrace DOF section
collect2: ld returned 1 exit status
cabal: Error: some packages failed to install:
hscolour-1.17 failed during the building phase. The exception was:
ExitFailure 1
}}}
New description:
When building an executable on 10.5, the link step fails. Problem occurs
with 7.0.2 i386 and x86_64 builds of 7.0.2 on Mac OS X 10.5. Same
compilers work find on 10.6.
Example log from building !HsColour:
{{{
Linking dist/build/HsColour/HsColour ...
error: Could not compile reconstructed dtrace script:
Unhandled typedefs encoding version v2
provider HaskellEvent {
probe startup(EventCapNo);
probe gc__work(EventCapNo);
probe gc(int, double, long,...)(EventCapNo);
probe gc__done(EventCapNo);
probe thread_wakeup(EventCapNo,EventThreadID,EventCapNo);
probe thread__runnable(EventCapNo,EventThreadID);
probe migrate__thread(EventCapNo,EventThreadID,EventCapNo);
probe create__thread(EventCapNo,EventThreadID);
probe gc__start(EventCapNo);
probe gc__end(EventCapNo);
probe stop__thread(EventCapNo,EventThreadID,EventThreadStatus);
probe run__thread(EventCapNo,EventThreadID);
probe user__msg(EventCapNo,char *);
};
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent
provider
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent module
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent
function
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent name
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent args
ld: error creating dtrace DOF section
collect2: ld returned 1 exit status
cabal: Error: some packages failed to install:
hscolour-1.17 failed during the building phase. The exception was:
ExitFailure 1
}}}
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4996#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] #4996: can't link executables due to dtrace error on Mac OS X 10.5
#4996: can't link executables due to dtrace error on Mac OS X 10.5 --+- Reporter: MtnViewMark | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.0.2 Resolution: wontfix | Keywords: dtrace osx mac 10.5 Testcase: | Blockedby: Difficulty: | Os: MacOS X Blocking: | Architecture: Unknown/Multiple Failure: GHC doesn't work at all | --+- Changes (by igloo): * status: new = closed * resolution: = wontfix Comment: Thanks for the report. Unfortunately, we are no longer able to actively support OS X 10.5. However, if you build GHC yourself on 10.5 then I believe it will work fine, and we will happily accept a patch to make builds made on 10.6 also work on 10.5. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4996#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] #4997: Mac installers are missing ghc cabal guides
#4997: Mac installers are missing ghc cabal guides -+-- Reporter: MtnViewMark |Owner: igloo Type: bug | Status: new Priority: highest |Milestone: 7.2.1 Component: None | Version: 7.0.2 Keywords:| Testcase: Blockedby:| Difficulty: Os: MacOS X | Blocking: Architecture: Unknown/Multiple | Failure: Installing GHC failed -+-- Changes (by igloo): * owner: = igloo * priority: normal = highest * milestone: = 7.2.1 Comment: Thanks for the report. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4997#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] #4977: Warning about unqualified implicit imports
#4977: Warning about unqualified implicit imports -+-- Reporter: Lemming |Owner: igloo Type: feature request | Status: new Priority: highest |Milestone: 7.2.1 Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonpj): * owner: = igloo Comment: In an odd moment I wrote the documentation. I've also changed the behaviour slightly to warn only for ''unqualified'' imports. I agree with Lemming that this is the case we really want to warn about. I attach the patch because I can't make the documentation on my laptop and I don't want to break the built by a formatting error. Ian can you check and apply? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4977#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
[GHC] #4998: performance regressions
#4998: performance regressions
-+--
Reporter: igloo |Owner:
Type: bug | Status: new
Priority: high |Milestone: 7.2.1
Component: Compiler | Version: 7.0.2
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
From http://www.haskell.org/pipermail/glasgow-haskell-
users/2011-March/020122.html :
{{{
A couple of the measurement differences to GHC 7.0.1 look strange, just
letting you know.
fannkuchredux,ghc,3
fasta,ghc,1
}}}
http://alioth.debian.org/scm/viewvc.php/shootout/website/websites/u64q/data/ndata.csv?root=shootoutr1=1.628r2=1.629
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4998
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] #4999: build fails on powerpc: error: 'ObjectCode' has no member named 'misalignment'
#4999: build fails on powerpc: error: 'ObjectCode' has no member named
'misalignment'
+---
Reporter: nomeata | Owner:
Type: bug | Status: new
Priority: normal | Component: Runtime System
Version: 7.0.2|Keywords:
Testcase: | Blockedby:
Os: Linux|Blocking:
Architecture: powerpc | Failure: Building GHC failed
+---
When building the Debian package for ghc-7.0.2 on powerpc, the build
fails. Build log at
https://buildd.debian.org/fetch.cgi?pkg=ghc;ver=7.0.2-1;arch=powerpc;stamp=1299367262
and relevant portion is:
{{{
rts/Linker.c:2440:0:
error: 'ObjectCode' has no member named 'misalignment'
}}}
This is the code in question:
{{{
static void ocFlushInstructionCache( ObjectCode *oc )
{
/* The main object code */
ocFlushInstructionCacheFrom(oc-image + oc-misalignment,
oc-fileSize);
/* Jump Islands */
ocFlushInstructionCacheFrom(oc-symbol_extras, sizeof(SymbolExtra) *
oc-n_symbol_extras);
}
}}}
and it is inside
{{{
#ifdef powerpc_HOST_ARCH
}}}
The misalignment field is defined as
{{{
#ifndef USE_MMAP
#ifdef darwin_HOST_OS
, int misalignment
#endif
#endif
}}}
And USE_MMAP is true if
{{{
#if defined(linux_HOST_OS) || defined(freebsd_HOST_OS) || \
defined(dragonfly_HOST_OS) || defined(netbsd_HOST_OS ) || \
defined(openbsd_HOST_OS ) || \
( defined(darwin_HOST_OS ) !defined(powerpc_HOST_ARCH) ) || \
defined(kfreebsdgnu_HOST_OS) \
/* Don't use mmap on powerpc-apple-darwin as mmap doesn't support
* reallocating but we need to allocate jump islands just after each
* object images. Otherwise relative branches to jump islands can fail
* due to 24-bits displacement overflow.
*/
}}}
(last entry added by Debian, but unrelated to this bug).
It seems that the correct line here should be
{{{
( !defined(darwin_HOST_OS ) defined(powerpc_HOST_ARCH) ) || }}}
so that powerpc builds not on darwin use MMAP?
Also, I guess the failing line should be modified to also work in the
absence of the misalignment flag.
I’d be grateful if you could tell me what exactly to patch here, as I’m
not confident with the inner workings of the rts and even if I get it to
compile, I would not be sure that it’s correct.
Thanks,
Joachim
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4999
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] #4999: build fails on powerpc: error: 'ObjectCode' has no member named 'misalignment'
#4999: build fails on powerpc: error: 'ObjectCode' has no member named 'misalignment' +--- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.0.2|Keywords: Testcase: | Blockedby: Os: Linux|Blocking: Architecture: powerpc | Failure: Building GHC failed +--- Changes (by PHO): * cc: pho@… (added) Comment: Hmm... I think we can't use mmap for powerpc builds not only on darwin but on every operation systems, since relative branches with 24-bits displacement should not be darwin specific. So the correct fix would be to disable mmap and enable oc-misalignment when defined(powerpc_HOST_ARCH). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4999#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] #4996: can't link executables due to dtrace error on Mac OS X 10.5
#4996: can't link executables due to dtrace error on Mac OS X 10.5 --+- Reporter: MtnViewMark | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.0.2 Resolution: wontfix | Keywords: dtrace osx mac 10.5 Testcase: | Blockedby: Difficulty: | Os: MacOS X Blocking: | Architecture: Unknown/Multiple Failure: GHC doesn't work at all | --+- Changes (by PHO): * cc: pho@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4996#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] #4980: Warning about module abbreviation clashes
#4980: Warning about module abbreviation clashes -+-- Reporter: Lemming |Owner: Type: feature request | Status: new Priority: normal|Milestone: 7.4.1 Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by malcolm.wallace@…): I can see no case in which a shared module abbreviation could ever lead to a program doing the wrong thing. If there is a genuine ambiguity about the referent of an identifier, it will already be reported as an error. This warning request seems to be about avoiding future compile errors in this module, due to changes in other modules. But if you are refactoring code in other modules, you should always at least expect the possibility of consequent breakage in the modules that import them - that is part of the joy of static checking. It seems just as likely to me that the future refactoring could *erroneously* introduce a clashing identifier, as that the clashing identifier would be deliberate. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4980#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
