From trac at galois.com Thu May 1 03:43:46 2008 From: trac at galois.com (GHC) Date: Thu May 1 03:38:11 2008 Subject: [GHC] #2255: Improve SpecConstr for free variables Message-ID: <046.8df476ad68a5391260ec75cd3c9c045f@localhost> #2255: Improve SpecConstr for free variables -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- This ticket records a suggestion for improving `SpecConstr`, so we don't lose it. The original `SpecConstr` transformation is described in "[http://research.microsoft.com/%7Esimonpj/papers/spec-constr Call pattern specialisation for Haskell]". Consider this program {{{ f x = let g y = ...case x of { z:zs -> e1; [] -> e2 } ... in ...case x of z:zs -> if ... then g 3 else g 4 [] -> ... }}} Here 'x' is free in 'g', but x's value is known at g's call sites. It's not enough just to know "x is a cons" inside g; we must also have access to z,zs. So perhaps the thing to do is to imagine lambda-lifting 'g' to become 'gl' thus: {{{ gl x y = ...case x of { z:zs -> e1; [] -> e2 } ... f x = ...case x of z:zs -> if ... then gl x 3 else gl x 4 [] -> ... }}} Now the `SpecConstr` transformation will apply nicely. And it's arguably a bad shortcoming that currently the mere act of lambda lifting can affect how effective `SpecConstr` is. Of course, we only want to lambda-lift wrt the parameters that'll be specialised, so this transformation probably wants to be done at the same time as the rest of `SpecConstr`. I don't have much idea of how hard that'd be, but it's a nice idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 04:25:40 2008 From: trac at galois.com (GHC) Date: Thu May 1 04:20:31 2008 Subject: [GHC] #2252: Extreme performance degradation on minor code change In-Reply-To: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> References: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> Message-ID: <054.0c4ef8481f03de60215a928091f6d362@localhost> #2252: Extreme performance degradation on minor code change ----------------------+----------------------------------------------------- Reporter: simona | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by simona): Gosh I hope this isn't happening since I used the timing results of the good code in a paper. Adding `-fno-full-laziness` to the compilation of `GoodPerform.hs` changes nothing (thankfully). Note also that the good performer is less likely to benefit from lazyness optimization since it first runs one loop for 1000 times, then another loop for 1000 times. The bad one has the potential for optimization since it runs two nearly identical calculations 1000 times. I might be possible, of course, that the loops in the good code are simple enough for optimizations to kick in whereas they are too big in the bad case. However, I ran other, more complex loops that have a good performance, too. I'm still assuming that it is the bad code that triggers some bad behavior. There is one side-effect in each loop iteration which tests some invariant on the result. There are quite a few computations that call the external library but which are pure, so I've wrapped them in `unsafePerformIO`. I don't know if that matters. Also, I should mention that both programs run in constant space (around 20MB virtual space), hence it's not a space leak that keeps back the tighter loop in `BadPerform.hs`. I compiled the code without any -O flags and I attach the two simplifier outputs. There are no `lvl_` strings in either file. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 05:17:39 2008 From: trac at galois.com (GHC) Date: Thu May 1 05:12:41 2008 Subject: [GHC] #2252: Extreme performance degradation on minor code change In-Reply-To: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> References: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> Message-ID: <054.e3aa4dd20ce0a48a83f3c68ee6b2cfdd@localhost> #2252: Extreme performance degradation on minor code change ----------------------+----------------------------------------------------- Reporter: simona | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by simonpj): Thanks. More info: what command line arguments are you using when compiling your program? In your `-ddump-simpl` I see invocations of `GHC.Base.$`, which suggests you aren't using -O. That never occurred to me. Do you get the same performance differences with -O? Of course, you still should not get these huge differences even without -O, but I'm interested because it'll give clues about where the problem is. The Core code looks ok to me, so I'm still v puzzled about why you would see big perf differences. I wonder if you can make this easier to reproduce, and at the same time give more clues. For example, suppose you trim out most of the functions the `fixpoint` calls, and leave just some reasonably-expensive thing (some random quadratically-expensive algorithm, say). Does the effect still happen? Or is it somehow connected to the code that is called (`meetAsym`, `equalityToInequalities`, etc)? And if so can you narrow down which code is the culprit, by stubbing out other parts? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 06:01:29 2008 From: trac at galois.com (GHC) Date: Thu May 1 05:56:10 2008 Subject: [GHC] #2252: Extreme performance degradation on minor code change In-Reply-To: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> References: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> Message-ID: <054.baad1b519355b572255daf66802d7cfc@localhost> #2252: Extreme performance degradation on minor code change ----------------------+----------------------------------------------------- Reporter: simona | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by simona): I've simplified the programs. This is what they do now: {{{ aconit:~/current/source/sparseDomain:1821$ rm -f tests/BadPerform.o && ghc-6.8.2 --make tests/BadPerform.hs -ddump-simpl > badSimpl.txt && time tests/BadPerform [1 of 1] Compiling Main ( tests/BadPerform.hs, tests/BadPerform.o ) Linking tests/BadPerform ... real 0m9.585s user 0m9.551s sys 0m0.033s aconit:~/current/source/sparseDomain:1822$ rm -f tests/GoodPerform.o && ghc-6.8.2 --make tests/GoodPerform.hs -ddump-simpl > goodSimpl.txt && time tests/GoodPerform [1 of 1] Compiling Main ( tests/GoodPerform.hs, tests/GoodPerform.o ) Linking tests/GoodPerform ... real 0m0.015s user 0m0.012s sys 0m0.002s }}} There are some fishy non-improving optimizations going on. As you suggested, I re-complied with optimizations: {{{ aconit:~/current/source/sparseDomain:1825$ rm -f tests/BadPerform.o && ghc-6.8.2 --make tests/BadPerform.hs -O -ddump-simpl > badSimplOpt.txt && time tests/BadPerform [1 of 1] Compiling Main ( tests/BadPerform.hs, tests/BadPerform.o ) Linking tests/BadPerform ... real 0m19.101s user 0m19.044s sys 0m0.054s aconit:~/current/source/sparseDomain:1826$ rm -f tests/GoodPerform.o && ghc-6.8.2 --make tests/GoodPerform.hs -O -ddump-simpl > goodSimplOpt.txt && time tests/GoodPerform [1 of 1] Compiling Main ( tests/GoodPerform.hs, tests/GoodPerform.o ) Linking tests/GoodPerform ... real 0m18.974s user 0m18.914s sys 0m0.056s }}} I have also tried to radically simplify the `fixpoint` function which would then return immediately. It is so simple, that I could build a cabal package that doesn't link to the simplex solver and which would therefore be easy to build for you. However, I'm not sure if you can see the difference anymore: Repeating the good case one million times takes 0.4 seconds, repeating the bad case one million times (which does twice the amount of work in each iteration) takes 1.4 seconds. Repeating the good case two million times takes 0.8 seconds, as expected. I hope the attached simplifier outputs are informative enough. Note that I've updated the source files too! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 06:52:06 2008 From: trac at galois.com (GHC) Date: Thu May 1 06:47:02 2008 Subject: [GHC] #2252: Extreme performance degradation on minor code change In-Reply-To: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> References: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> Message-ID: <054.3d622399b1eaedf0397c7e2542dc6498@localhost> #2252: Extreme performance degradation on minor code change ----------------------+----------------------------------------------------- Reporter: simona | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by simonpj): Crumbs! So switching on -O makes `GoodPerform` run slowly too! Can you try with `-fno-state-hack`? How fast do you ''expect'' this to run? For example, if you do just one of the fixpoints 1000 times, is that fast? Is it supposed to be fast? I'm trying to ask whether `GoodPerform` is going bizarrely fast or `BadPerform` is going bizarrely slowly. Well done cutting down `fixpoint`. It'd be a huge help if you could so so some more, so that GLPK, gmp etc were not needed. If it runs too fast, just do something expensive, like `min [i+j | i <- [1..n], j <- [1..n]]`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 07:04:18 2008 From: trac at galois.com (GHC) Date: Thu May 1 06:58:42 2008 Subject: [GHC] #2247: GHC accepts FD violations, unless the conflicing instances are used In-Reply-To: <044.b5dc7ac6137d6de05ce0c6a9f5daf089@localhost> References: <044.b5dc7ac6137d6de05ce0c6a9f5daf089@localhost> Message-ID: <053.7392f87a2645de89bc2697cc956d6455@localhost> #2247: GHC accepts FD violations, unless the conflicing instances are used -------------------------------------+-------------------------------------- Reporter: claus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: TF vs FD | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: I assume you are using some flags? {{{ ghc -c -XFunctionalDependencies Foo.hs -XMultiParamTypeClasses Foo.hs:5:1: Illegal instance declaration for `FD a b' (All instance types must be of the form (T a1 ... an) where a1 ... an are distinct type *variables* Use -XFlexibleInstances if you want to disable this.) In the instance declaration for `FD a b' }}} Adding `-XFlexibleInstances` gives {{{ bash-3.1$ ghc -c -XFunctionalDependencies Foo.hs -XMultiParamTypeClasses -XFlexibleInstances Foo.hs:5:1: Constraint is no smaller than the instance head in the constraint: CFD a b (Use -fallow-undecidable-instances to permit this) In the instance declaration for `FD a b' Foo.hs:5:1: Illegal instance declaration for `FD a b' (the Coverage Condition fails for one of the functional dependencies; Use -fallow-undecidable-instances to permit this) In the instance declaration for `FD a b' }}} In fact to get `Improve` to compile you need {{{ $gpj -c -XFunctionalDependencies -XMultiParamTypeClasses -XFlexibleInstances -fallow-undecidable-instances -XFlexibleContexts Foo.hs }}} The offending one is `-fallow-undecidable-instances`, and this ticket is an excellent example of #1241. Currently saying `-fallow-undecidable- instances` lifts the coverage condition. I acknowledge that this isn't the Right Thing in #1241, but it doesn't threaten type soundness (ie programs will not seg-fault). So I'm going to close this bug and link to it from #1241. Re-open if I have misunderstood. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 07:05:07 2008 From: trac at galois.com (GHC) Date: Thu May 1 06:59:37 2008 Subject: [GHC] #1241: Functional dependency Coverage Condition is lifted, and should not be In-Reply-To: <044.2ed16cd4afdeeb3a7ba64f06a8572122@localhost> References: <044.2ed16cd4afdeeb3a7ba64f06a8572122@localhost> Message-ID: <053.7c95ee70f4c918af945ed0538c14e6da@localhost> #1241: Functional dependency Coverage Condition is lifted, and should not be -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by simonpj): See also #2247, which gives an example of the confusing things that happen if we don't impose the Coverage Condition. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 08:25:14 2008 From: trac at galois.com (GHC) Date: Thu May 1 08:20:08 2008 Subject: [GHC] #2252: Extreme performance degradation on minor code change In-Reply-To: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> References: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> Message-ID: <054.aa40b6b69510919a5d39980290f8c50d@localhost> #2252: Extreme performance degradation on minor code change ----------------------+----------------------------------------------------- Reporter: simona | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by simona): I think (and hope) that BadPerform is going bizarrely slow. BadPerform runs the same loop twice and should thus only be twice as slow as GoodPerform, not 800 times as slow. I ran more complex examples a million times and got something in the range of 4-8s which means that each fixpoint computation (involving 8 iterations around the loop) takes 4-8us which is actually quite fast since that would mean that some complicated list operations and a several calls to simplex are done in a few thousand instructions on this 2.X GHz machine. But the numbers did seem to make sense in relation to each other. I tried to add the `-fno-state-hack` flag but that didn't change anything. I copied stubs of the relevant function into a new module called `Fake.hs` -- I tried putting the functions directly into `BadPerform.hs` but that it went as fast as `GoodPerform.hs`. I made the `fixpoint` function go slower by adding the test `minimum [i+j | i <- [1..100], j <- [1..100]]<3` as you suggested. The results: {{{ 1858$ rm -f tests/GoodPerform.o && ghc-6.8.2 --make GoodPerform.hs && time GoodPerform real 0m0.008s user 0m0.004s sys 0m0.004s 1859$ rm -f tests/BadPerform.o && ghc-6.8.2 --make BadPerform.hs && time BadPerform Linking BadPerform ... real 0m2.923s user 0m2.911s sys 0m0.010s }}} I will update the two source files and their simplifier dump. I'll also add `Fake.hs`. Thanks for looking into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 09:33:21 2008 From: trac at galois.com (GHC) Date: Thu May 1 09:27:46 2008 Subject: [GHC] #2247: GHC accepts FD violations, unless the conflicing instances are used In-Reply-To: <044.b5dc7ac6137d6de05ce0c6a9f5daf089@localhost> References: <044.b5dc7ac6137d6de05ce0c6a9f5daf089@localhost> Message-ID: <053.aa2f83365a07e66da42b7b6ff562c2cc@localhost> #2247: GHC accepts FD violations, unless the conflicing instances are used -------------------------------------+-------------------------------------- Reporter: claus | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: TF vs FD | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by claus): * status: closed => reopened * resolution: duplicate => Comment: Replying to [comment:2 simonpj]: > I assume you are using some flags? always!-) in fact, as you can see from this little example, using GHC has become very inconvenient due to the proliferation of flags. first, i have to iterate to figure out which flags i need to get my code accepted. then, i have to do the same again because the GHCi session does *not* inherit the `LANGUAGE` pragmas from the module i load.. it doesn't help that `UndecidableInstances` is needed so often for perfectly decidable code. in this case, delegating to another constraint that is no smaller than the original already requires this extension, independent of coverage. > In fact to get `Improve` to compile you need > {{{ > $gpj -c -XFunctionalDependencies > -XMultiParamTypeClasses > -XFlexibleInstances > -fallow-undecidable-instances > -XFlexibleContexts > Foo.hs > }}} > The offending one is `-fallow-undecidable-instances`, and this ticket is an excellent example of #1241. Currently saying `-fallow-undecidable- instances` lifts the coverage condition. I acknowledge that this isn't the Right Thing in #1241, but it doesn't threaten type soundness (ie programs will not seg-fault). > > So I'm going to close this bug and link to it from #1241. Re-open if I have misunderstood. yes and no. yes, for the current implementation of FDs in GHC; no, in principle. neither coverage nor fullness appear necessary for confluence (cf. [http://www.cs.kuleuven.be/~toms/Research/papers/tfp08-full.pdf Restoring Confluence for Functional Dependencies, T. Schrijvers, M. Sulzmann]), and a confluent implementation of FDs should raise all inconsistencies, with the exception of dead code (the ticket example was meant to highlight this gap, see also the discussion of forward inference in http://www.haskell.org/pipermail/haskell-cafe/2008-April/042219.html). the variation shows clearly that GHC drops FD/improvement-related information, so that not even all conflicts in live constraints are flagged. it seems that one of the places where improvement-related information is dropped is separate compilation (if all FD-relevant constraints were cached as they arise, and preserved in interface files, inlining across module boundaries ought to make no difference, right?). note also this reduced variation {{{ class FD a b | a -> b instance CFD a b => FD a b class FD a b => CFD a b instance CFD Bool Char -- instance CFD Bool Bool }}} which is accepted by Hugs (in Hugs mode), in spite of its presumably stricter conditions. yet, on uncommenting the second `CFD` instance, Hugs notices the FD-inconsistency immediately, while GHCi doesn't (and the other variations show that GHC won't necessarily notice the issue later, either). so, the two tickets are linked, but if one looks beyond ruling out this kind of example (and #1241 seemed to tend in the direction of finding less restrictive conditions than GHC has, not more restrictive conditions than Hugs has), there seems to be more going on. at the very least, this ticket should be looked into when #1241 gets fixed, in case it isn't covered by the same fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 09:59:43 2008 From: trac at galois.com (GHC) Date: Thu May 1 09:54:08 2008 Subject: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints Message-ID: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@localhost> #2256: Incompleteness of type inference: must quantify over implication constraints -------------------------+-------------------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Consider this program (from Iavor) {{{ f x = let g y = let h :: Eq c => c -> () h z = sig x y z in () in fst x sig :: Eq (f b c) => f () () -> b -> c -> () sig _ _ _ = () }}} This example is rejected by both Hugs and GHC but I think that it is a well typed program. The Right Type to infer for g is this: {{{ g :: forall b. (forall c. Eq c => Eq (b,c)) => b -> () }}} but GHC never quantifies over implication constraints at the moment. As a result, type inference is incomplete (although in practice no one notices). I knew about this, but I don't think it's recorded in Trac, hence this ticket. Following this example through also led me to notice a lurking bug: see "BUG WARNING" around line 715 of `TcSimplify`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 12:23:25 2008 From: trac at galois.com (GHC) Date: Thu May 1 12:17:50 2008 Subject: [GHC] #2254: have Control.Arrow re-export (>>>) and (<<<) In-Reply-To: <043.08bb6362803b2111fd61efa7055513a2@localhost> References: <043.08bb6362803b2111fd61efa7055513a2@localhost> Message-ID: <052.ccfd46c2a14c984076a3327d123019f4@localhost> #2254: have Control.Arrow re-export (>>>) and (<<<) -------------------------------+-------------------------------------------- Reporter: ross | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Comment (by ganesh): I support this; I think it's unnecessarily burdensome on users to have to import Control.Category when using arrows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 12:45:50 2008 From: trac at galois.com (GHC) Date: Thu May 1 12:40:48 2008 Subject: [GHC] #1544: Derived Read instances for recursive datatypes with infix constructors are too inefficient In-Reply-To: <059.876fe881e6bc9b43ab179d4b6da29ec1@localhost> References: <059.876fe881e6bc9b43ab179d4b6da29ec1@localhost> Message-ID: <068.9c2ed2500400a9aec7143618ec1851c6@localhost> #1544: Derived Read instances for recursive datatypes with infix constructors are too inefficient ----------------------------------+----------------------------------------- Reporter: jcpetruzza@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Comment (by simonpj): See [http://www.cs.uu.nl/wiki/bin/view/Center/TTTAS#The_internals_for_a_better_Deriv The internals for a better Deriving Read and Write] which describes progress by Doaitse and his colleagues. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 17:25:07 2008 From: trac at galois.com (GHC) Date: Thu May 1 17:25:52 2008 Subject: [GHC] #2257: validate hangs in configure Message-ID: <041.16fba6c404adcf566b7f71a6b9078150@localhost> #2257: validate hangs in configure -----------------------+---------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Running ./validate on a freshly updated HEAD results in the script hanging during the configuration process. Here's what's on the screen: {{{ checking whether float word order is big endian... no checking for nlist in -lelf... no checking leading underscore in symbol names... no checking whether ld understands -x... yes checking whether ld is GNU ld... yes checking for .subsections_via_symbols... no checking for GNU non-executable stack support... no checking for clock_gettime in -lrt... yes checking for clock_gettime... yes checking for timer_create... yes checking for timer_settime... yes checking for a working timer_create(CLOCK_REALTIME)... }}} HEre's what 'top' has to say about what is running: {{{ PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 29457 nr 20 0 2000 480 368 R 88 0.0 9:18.12 conftest }}} And strace of that process reveals an endless stream of these: {{{ --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- sigreturn() = ? (mask now []) }}} The system is a 32-bit Debian testing/unstable, uname -a says {{{ Linux homedog 2.6.24-1-686 #1 SMP Sat Apr 19 00:37:55 UTC 2008 i686 GNU/Linux }}} The CPU is a dual-core AMD FX-60: {{{ processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 35 model name : AMD Athlon(tm) 64 FX-60 Dual Core Processor stepping : 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 18:41:54 2008 From: trac at galois.com (GHC) Date: Thu May 1 18:36:48 2008 Subject: [GHC] #2252: Extreme performance degradation on minor code change In-Reply-To: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> References: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> Message-ID: <054.f8c8f2a69a949bb7577d84d667033c14@localhost> #2252: Extreme performance degradation on minor code change ----------------------+----------------------------------------------------- Reporter: simona | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by simonpj): You made a mistake in the new `GoodPerform.hs`; you wrote {{{ replicateM_ 1000 $ do --res1 <- fixpoint initial bottom bottom vn 1 --unless (res1 `subset` res1) $ putStrLn "something's wrong" res2 <- fixpoint initial bottom bottom vn 1 unless (res2 `subset` res2) $ putStrLn "something's wrong" }}} but you meant to use two calls to `replicateM_`, didn't you? Anyway I know what's going on. Here is the crucial fragment of the two forms, after desguaring: {{{ Bad: replicateM_ 1000 (f 10 >>= (\res1 -> f 20 >>= (\res2 -> return ()))) Good: replicateM_ 1000 (f 10) >> replicateM_ 1000 (f 20) }}} The `f` is the `fixpoint` function; the `10` and `20` are the constant args to those two calls. Just look at it! The key point is that in both cases, the subexpression `(f 10)` is outside any lambdas, and hence is executed just once. It's just as I said, although obscured by clutter: the computation is unaffected by IO state, so there is no need for it to be repeated each time. Furthermore, in the `good` case, the call `(f 20)` is '''also#'' outside any lambdas, and ''hence is computed only once''. But in the `bad` case, the call `(f 20)` is inside the `(\ res1 -> ...)` abstraction, and so is computed once for each call of the (\res1...); that is 1000 times. So that's why there's the big difference. It is a little puzzling, but it becomes much clearer when you desugar the do-notation. The moral, as often, is that if you put a constant expression inside a loop, GHC will often compute it just once. But this occurs much more often in benchmarks than in real programs Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 18:51:29 2008 From: trac at galois.com (GHC) Date: Thu May 1 18:45:52 2008 Subject: [GHC] #2258: ghc --cleanup Message-ID: <044.6a7e7db2214398b58538f207783c755e@localhost> #2258: ghc --cleanup --------------------------------+------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- calling `ghc --make` generates a lot of files, `.o`, `.hi`, `.exe`, `.exe.manifest`, .. moreover, those files may be in different directories, etc. a nice way to get rid of all those leftovers would be a `ghc --cleanup`, with the same options and parameters as `ghc --make`, which would delete everything that `ghc --make` would generate. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 19:01:35 2008 From: trac at galois.com (GHC) Date: Thu May 1 19:02:17 2008 Subject: [GHC] #2257: validate hangs in configure In-Reply-To: <041.16fba6c404adcf566b7f71a6b9078150@localhost> References: <041.16fba6c404adcf566b7f71a6b9078150@localhost> Message-ID: <050.8d8bccc01cfca09ba85cbdb9b15c5219@localhost> #2257: validate hangs in configure -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------------+---------------------------------------------- Comment (by nr): I did a little digging into the file that's hanging, and I notice it calls usleep and waits for a timer event. It's hanging, and if interrupted, it shows this backtrace: {{{ (gdb) bt #0 handler (i=26) at conftest.c:109 #1 #2 0xb7f163d6 in _dl_fixup () from /lib/ld-linux.so.2 #3 0xb7f1bc50 in _dl_runtime_resolve () from /lib/ld-linux.so.2 #4 0x080488a9 in main () at conftest.c:178 (gdb) }}} Line 178 is the call to usleep() and line 109 is the VTALARM handler installed by sigaction(). I note that the man page for usleep contains these warnings: {{{ CONFORMING TO 4.3BSD, POSIX.1-2001. POSIX.1-2001 declares this function obsolete; use nanosleep(2) instead. }}} and {{{ The interaction of this function with the SIGALRM signal, and with other timer functions such as alarm(2), sleep(3), nanosleep(2), setitimer(2), timer_create(3), timer_delete(3), timer_getoverrun(3), timer_gettime(3), timer_settime(3), ualarm(3) is unspecified. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 19:11:17 2008 From: trac at galois.com (GHC) Date: Thu May 1 19:12:00 2008 Subject: [GHC] #2257: validate hangs in configure In-Reply-To: <041.16fba6c404adcf566b7f71a6b9078150@localhost> References: <041.16fba6c404adcf566b7f71a6b9078150@localhost> Message-ID: <050.38f76bc186f8135692ef98d4f75e1ed6@localhost> #2257: validate hangs in configure -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------------+---------------------------------------------- Comment (by nr): Replacing usleep with nanosleep changes nothing. But linking the program statically makes it terminate instantly. So there is some kind of bad interaction between the dynamic linker and this test program. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 19:15:39 2008 From: trac at galois.com (GHC) Date: Thu May 1 19:16:22 2008 Subject: [GHC] #2257: validate hangs in configure In-Reply-To: <041.16fba6c404adcf566b7f71a6b9078150@localhost> References: <041.16fba6c404adcf566b7f71a6b9078150@localhost> Message-ID: <050.cf8ab9e20d47ee66083030d9dc67dc0e@localhost> #2257: validate hangs in configure -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------------+---------------------------------------------- Comment (by nr): OK, if I remove an LD_PRELOAD environment variable, which points to a wrapper around getaddrinfo, things work. Perhaps the configure script should do something about checking for LD_PRELOAD? I'm leaving this ticket open because others will know how best to resolve it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 1 19:36:15 2008 From: trac at galois.com (GHC) Date: Thu May 1 19:36:57 2008 Subject: [GHC] #2257: validate hangs in configure In-Reply-To: <041.16fba6c404adcf566b7f71a6b9078150@localhost> References: <041.16fba6c404adcf566b7f71a6b9078150@localhost> Message-ID: <050.b438b8a77adaa3c489500e45cfd94668@localhost> #2257: validate hangs in configure -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------------+---------------------------------------------- Comment (by nr): I take it back, both ways. 1. Static linking doesn't solve the problem after all. Must have been an error between the keyboard and the chair 1. If you replace usleep with nanosleep, and you are willing to wait a long time for configure to finish, it finishes eventually. Or at least it did once. 1. Further experimenting with variations on the test program shows that the program hangs on the second call to timer_settime. For all I know this is a kernel problem I am out of my depth. Help! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 2 03:40:03 2008 From: trac at galois.com (GHC) Date: Fri May 2 03:34:57 2008 Subject: [GHC] #2252: Extreme performance degradation on minor code change In-Reply-To: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> References: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> Message-ID: <054.e645860cde2c8bc9075df224c013e518@localhost> #2252: Extreme performance degradation on minor code change ----------------------+----------------------------------------------------- Reporter: simona | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simona): * status: new => closed * resolution: => invalid Comment: Ok, I think I get it. I've added a call to `getArgs` which makes both loops run quite slowly. The new timings are unfortunately not in my favour anymore (I'm comparing two different implementations) so I have to think of a way to explain that at the conference... Thanks for taking the time to look into this. Axel. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 2 06:58:05 2008 From: trac at galois.com (GHC) Date: Fri May 2 06:52:35 2008 Subject: [GHC] #1861: Uncompilable code generated In-Reply-To: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> References: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> Message-ID: <053.fbff135965e9ed574d2f0fa9aca30db2@localhost> #1861: Uncompilable code generated ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by simonpj): So the problem here is a narrow one: how does one write down the IEEE Double constant for infinity, in such a way that the C compiler understands it. Does one write "1e400" or "1e10000000" (both are too big to be represented) or is there a kosher way to do it? Or can one say "0xblablah" where that's the IEEE bit pattern for infinity? Or perhaps "1/0" would do? I don't know. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 2 07:01:04 2008 From: trac at galois.com (GHC) Date: Fri May 2 06:55:34 2008 Subject: [GHC] #2245: Numeric literal printed wrong in error message In-Reply-To: <044.08dd2bddd379c7c8cb24c2c904f28812@localhost> References: <044.08dd2bddd379c7c8cb24c2c904f28812@localhost> Message-ID: <053.72399aa4e3da3901881921dd8bbc76b9@localhost> #2245: Numeric literal printed wrong in error message ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: cf #1861, which is related. Nevertheless this ticket is a distinct bug in GHC's error message. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 2 12:07:19 2008 From: trac at galois.com (GHC) Date: Fri May 2 12:01:38 2008 Subject: [GHC] #2238: panic nameModule tpl_B1{v} In-Reply-To: <044.2c7ef9e7b09c867edd5544536ef8fbf1@localhost> References: <044.2c7ef9e7b09c867edd5544536ef8fbf1@localhost> Message-ID: <053.c6f1b5452310ccfc06afd860433c799a@localhost> #2238: panic nameModule tpl_B1{v} ----------------------+----------------------------------------------------- Reporter: claus | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2238 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: After a manual merge the test still failed, so I've just made the test an expected fail on 6.8 instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 2 12:09:10 2008 From: trac at galois.com (GHC) Date: Fri May 2 12:03:31 2008 Subject: [GHC] #2188: TH scoping problem In-Reply-To: <044.2bbd6efb87952e5e65fa7406d244cf0e@localhost> References: <044.2bbd6efb87952e5e65fa7406d244cf0e@localhost> Message-ID: <053.d7b3eabe74af59db89225ab5e32c3794@localhost> #2188: TH scoping problem ------------------------------+--------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: TH_scope | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: The 6.8 branch is already OK, so closing this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 2 19:20:12 2008 From: trac at galois.com (GHC) Date: Fri May 2 19:14:43 2008 Subject: [GHC] #2245: Numeric literal printed wrong in error message In-Reply-To: <044.08dd2bddd379c7c8cb24c2c904f28812@localhost> References: <044.08dd2bddd379c7c8cb24c2c904f28812@localhost> Message-ID: <053.d1ada94e0ef4a3162cbea683f93fd5de@localhost> #2245: Numeric literal printed wrong in error message ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonpj): * priority: normal => low * milestone: => 6.10 branch Comment: The underlying problem here is this. The lexer sees the token `1.5e-4` and from that produces a Rational. See `Lexer.x`, and the function `readRational`. In this case it'll produce something like `15 :% 100000` The trouble is that when printing it out in an error message, it's hard to reverse-engineer that into exactly what the programmer wrote. What we do at the moment (in Pretty.rational) is to convert to Double and show that. This will go wrong if there isn't an exact representation for the constant in Double -- and that's what is happening to Lennart. The Right Thing is for a `HsLit.HsFractional` to contain not a Rational, but rather something like a {{{ data FloatLit = FL { fl_int :: Integer -- Part before decimal point , fl_frac :: Maybe Integer -- Part after decimal point (if any) , fl_exp :: Maybe Integer -- Exponent (if any) } }}} This would record exactly what the user wrote. Then we can convert to a Rational later, but meanwhile we can print it accurately in error messages. Simple, but a bit fiddly, so I'm not going to do it today. The above notes just record the plan. Yell if it's important to get it done sooner. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 05:07:03 2008 From: trac at galois.com (GHC) Date: Sat May 3 05:01:24 2008 Subject: [GHC] #2259: can not make `if` look nice in a `do` Message-ID: <043.8d71ae8d538a76eae220b1ed21b45b55@localhost> #2259: can not make `if` look nice in a `do` -----------------------+---------------------------------------------------- Reporter: jsnx | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- The handling of {{{if}}} within a {{{do}}} block is not consistent with it's handling outside of it. {{{ import Text.ParserCombinators.Parsec date AesthErr = LineTooLong SourcePos Int -- works fine shorty0 len = do s <- manyTill anyChar newLine case length s > len of True -> do pos <- getPosition return $ Left $ LineTooLong pos len _ -> return $ Right s -- epic fail shorty1 len = do s <- manyTill anyChar newLine if length s > len then do pos <- getPosition return $ Left $ LineTooLong pos len else return $ Right s -- epic fail shorty2 len = do s <- manyTill anyChar newLine if length s > len then fmap (Left . flip LineTooLong len) getPosition else return $ Right s }}} Whereas this is fine: {{{ f n = if n > 7 then "Great!" else "Less!" }}} Is this something I can fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 08:36:44 2008 From: trac at galois.com (GHC) Date: Sat May 3 08:31:03 2008 Subject: [GHC] #2259: can not make `if` look nice in a `do` In-Reply-To: <043.8d71ae8d538a76eae220b1ed21b45b55@localhost> References: <043.8d71ae8d538a76eae220b1ed21b45b55@localhost> Message-ID: <052.42ee2a82cdfd78a0f84f55303028fca6@localhost> #2259: can not make `if` look nice in a `do` -------------------------------+-------------------------------------------- Reporter: jsnx | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.8.2 Severity: minor | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Thanks for the report. However, GHC is just following the language standard here. There is a proposal to fix this for Haskell' (the next version of the language standard): http://hackage.haskell.org/trac /haskell-prime/wiki/DoAndIfThenElse -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 08:43:44 2008 From: trac at galois.com (GHC) Date: Sat May 3 08:38:01 2008 Subject: [GHC] #2244: load in GHCi doesn't work with UTF-8 filenames In-Reply-To: <047.b0858d6d8758a91eff606da681db9fc0@localhost> References: <047.b0858d6d8758a91eff606da681db9fc0@localhost> Message-ID: <056.328f1e589dd37be6d40b877e00bdf777@localhost> #2244: load in GHCi doesn't work with UTF-8 filenames ----------------------+----------------------------------------------------- Reporter: malebria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > When I try to load a file with a UTF-8 character, I got: > > Prelude> :load P?blico/codigo/haskell/Hora.hs > > : can't find file: P?blico/codigo/haskell/Hora.hs > > With the command line it goes fine: > > malebria@quindinho:~$ ghci P?blico/codigo/haskell/Hora.hs > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > [1 of 1] Compiling Hora ( P?blico/codigo/haskell/Hora.hs, > interpreted ) New description: When I try to load a file with a UTF-8 character, I got: {{{ Prelude> :load P?blico/codigo/haskell/Hora.hs : can't find file: P?blico/codigo/haskell/Hora.hs }}} With the command line it goes fine: {{{ malebria@quindinho:~$ ghci P?blico/codigo/haskell/Hora.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Hora ( P?blico/codigo/haskell/Hora.hs, interpreted ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 08:57:00 2008 From: trac at galois.com (GHC) Date: Sat May 3 08:51:23 2008 Subject: [GHC] #2244: load in GHCi doesn't work with UTF-8 filenames In-Reply-To: <047.b0858d6d8758a91eff606da681db9fc0@localhost> References: <047.b0858d6d8758a91eff606da681db9fc0@localhost> Message-ID: <056.3796a45206b0c3ce9ee80f991ed78adb@localhost> #2244: load in GHCi doesn't work with UTF-8 filenames ----------------------+----------------------------------------------------- Reporter: malebria | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch Comment: Thanks for the report. I suspect that this is because the IO functions ignore all but the low 8 bits of Strings. We should do something to make this work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 10:06:06 2008 From: trac at galois.com (GHC) Date: Sat May 3 10:00:23 2008 Subject: [GHC] #2258: ghc --cleanup In-Reply-To: <044.6a7e7db2214398b58538f207783c755e@localhost> References: <044.6a7e7db2214398b58538f207783c755e@localhost> Message-ID: <053.19e23317c5e8e2a58c8bc4d6af5e7b36@localhost> #2258: ghc --cleanup -----------------------------+---------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Also the stub `.c`/`.h` files. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 10:06:27 2008 From: trac at galois.com (GHC) Date: Sat May 3 10:00:44 2008 Subject: [GHC] #2254: have Control.Arrow re-export (>>>) and (<<<) In-Reply-To: <043.08bb6362803b2111fd61efa7055513a2@localhost> References: <043.08bb6362803b2111fd61efa7055513a2@localhost> Message-ID: <052.a194b0ce6d424301206ae75aee36db64@localhost> #2254: have Control.Arrow re-export (>>>) and (<<<) ----------------------------+----------------------------------------------- Reporter: ross | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 10:07:10 2008 From: trac at galois.com (GHC) Date: Sat May 3 10:01:28 2008 Subject: [GHC] #2253: Native code generator could do better In-Reply-To: <043.862f2d1bf55b0e0d2dddbf6af3659352@localhost> References: <043.862f2d1bf55b0e0d2dddbf6af3659352@localhost> Message-ID: <052.6c84130e7cf18b9a190d0a08ba821b93@localhost> #2253: Native code generator could do better --------------------------------------+------------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (NCG) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks don! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 10:10:58 2008 From: trac at galois.com (GHC) Date: Sat May 3 10:05:20 2008 Subject: [GHC] #2250: unpackFamily on Windows 2008 fails match In-Reply-To: <044.9136a0e7b8ebc803db4744ef0ab955c3@localhost> References: <044.9136a0e7b8ebc803db4744ef0ab955c3@localhost> Message-ID: <053.97868efd32feb5f92fe0aaa34f154a1b@localhost> #2250: unpackFamily on Windows 2008 fails match -------------------------------+-------------------------------------------- Reporter: larsv | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC Comment: Can you please attach a complete testcase? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 10:20:22 2008 From: trac at galois.com (GHC) Date: Sat May 3 10:14:40 2008 Subject: [GHC] #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs In-Reply-To: <046.59221d2fec02e33b156d46e404241b5d@localhost> References: <046.59221d2fec02e33b156d46e404241b5d@localhost> Message-ID: <055.926587c74baa7edc88a07838c883092d@localhost> #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs ----------------------+----------------------------------------------------- Reporter: oboudry | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: What we currently do is to add a `.exe` extension if there is no extension already. In your examples you already have an extension (`.0` or `.012`). The code is trivial to change, it's just a question of what behaviour we want. If we do change the behaviour, what extensions should mean that we don't add `.exe`? Obviously `.exe` should, but what about, e.g., `.scr`? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 10:38:46 2008 From: trac at galois.com (GHC) Date: Sat May 3 10:33:03 2008 Subject: [GHC] #2247: GHC accepts FD violations, unless the conflicing instances are used In-Reply-To: <044.b5dc7ac6137d6de05ce0c6a9f5daf089@localhost> References: <044.b5dc7ac6137d6de05ce0c6a9f5daf089@localhost> Message-ID: <053.43f790b53862a82b3acb521b32c11634@localhost> #2247: GHC accepts FD violations, unless the conflicing instances are used -------------------------------------+-------------------------------------- Reporter: claus | Owner: Type: bug | Status: reopened Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: TF vs FD | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * milestone: => _|_ Comment: #1241 is _|_, so I guess this should be too -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 11:54:44 2008 From: trac at galois.com (GHC) Date: Sat May 3 11:55:21 2008 Subject: [GHC] #2257: validate hangs in configure In-Reply-To: <041.16fba6c404adcf566b7f71a6b9078150@localhost> References: <041.16fba6c404adcf566b7f71a6b9078150@localhost> Message-ID: <050.a18c8be071f12d8f39306b7fe6a5bf85@localhost> #2257: validate hangs in configure --------------------------+------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: highest | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * priority: normal => highest * difficulty: => Unknown * milestone: => 6.8.3 Comment: My usleep manpage also says {{{ The interaction of this function with the SIGALRM signal, and with other timer functions such as alarm(), sleep(), nanosleep(), setitimer(), timer_create(), timer_delete(), timer_getoverrun(), timer_gettime(), timer_settime(), ualarm() is unspecified. }}} I can't see why it wouldn't work with `nanosleep`, though. I can't reproduce the problem. Can you attach the exact program (using nanosleep) that's being run, and the command line used to build and run it please? And can you check that `timer_delete` succeeds (it should return 0). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 12:28:38 2008 From: trac at galois.com (GHC) Date: Sat May 3 12:22:57 2008 Subject: [GHC] #2243: Can we remove IlxGen, Java, JavaGen, PrintJava? In-Reply-To: <048.1c657e7d878b9e4b4af84a238ffbca14@localhost> References: <048.1c657e7d878b9e4b4af84a238ffbca14@localhost> Message-ID: <057.6cdbee64300bc81182c550dbe4eba929@localhost> #2243: Can we remove IlxGen, Java, JavaGen, PrintJava? --------------------------+------------------------------------------------- Reporter: MarcWeber | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * summary: review and apply small patch removing no longer existing modules from ghc package db => Can we remove IlxGen, Java, JavaGen, PrintJava? * milestone: => 6.10 branch Comment: Thanks for the patches. I've already done some of the module-removing one, following your message to the mailing list. I'll leave this bug open as I don't know if `IlxGen`, `Java`, `JavaGen` and `PrintJava` can be completely removed now. The hasktags one doesn't validate (due to a number of warnings), so I haven't applied it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 12:33:44 2008 From: trac at galois.com (GHC) Date: Sat May 3 12:28:10 2008 Subject: [GHC] #2246: Numeric literal very badly optimized In-Reply-To: <044.ea64e9326ad25932314b8864281b1a7d@localhost> References: <044.ea64e9326ad25932314b8864281b1a7d@localhost> Message-ID: <053.981a2a0aebf2868a50286bb12f773d2f@localhost> #2246: Numeric literal very badly optimized ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the report. We could do with a way of writing tests for this sort of thing - perhaps grepping core, or checking that 2 modules produce the same core modulo alpha renaming. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 15:25:54 2008 From: trac at galois.com (GHC) Date: Sat May 3 15:26:32 2008 Subject: [GHC] #2257: validate hangs in configure In-Reply-To: <041.16fba6c404adcf566b7f71a6b9078150@localhost> References: <041.16fba6c404adcf566b7f71a6b9078150@localhost> Message-ID: <050.fff37b47329657655581fedcbf63fc09@localhost> #2257: validate hangs in configure --------------------------+------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: highest | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Comment (by nr): I've found a workaround; I insert a call to exit(4) just before the second call to timer_settime in aclocal.m4. The compiler builds and validates, but this is obviously a poor workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 16:22:45 2008 From: trac at galois.com (GHC) Date: Sat May 3 16:17:03 2008 Subject: [GHC] #2260: Non-ideal error message for misplaced LANGUAGE pragma Message-ID: <044.7cbacc8885ebc555467b0dece9c1a57d@localhost> #2260: Non-ideal error message for misplaced LANGUAGE pragma -------------------------+-------------------------------------------------- Reporter: TomMD | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.8.2 | Severity: trivial Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- Placing the LANGUAGE pragma anywhere besides the top results in it not being accepted - thus this should result in an error message. Trivially: {{{ import Data.Maybe {-# LANGUAGE EmptyDataDecls #-} data A }}} This would be minorly more annoying for TypeFamilies, who's error doesn't mention language extentions: "Data/Queue.hs:30:0: parse error (possibly incorrect indentation)" -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 17:13:38 2008 From: trac at galois.com (GHC) Date: Sat May 3 17:07:56 2008 Subject: [GHC] #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs In-Reply-To: <046.59221d2fec02e33b156d46e404241b5d@localhost> References: <046.59221d2fec02e33b156d46e404241b5d@localhost> Message-ID: <055.17055267f056548225f2d34f7e1f384e@localhost> #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs ----------------------+----------------------------------------------------- Reporter: oboudry | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Comment (by oboudry): Ok, I see. There are so many executable extension in Windows that it's probably better to leave it as it is and close this bug report. I just thought about .exe when creating this bug report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 3 17:19:12 2008 From: trac at galois.com (GHC) Date: Sat May 3 17:13:35 2008 Subject: [GHC] #2261: Foreign.C.Error.Errno should be an instance of (Eq, Ord, Show... others?) Message-ID: <044.d2c4495f54736a05cc5accbccdb5e35e@localhost> #2261: Foreign.C.Error.Errno should be an instance of (Eq,Ord, Show... others?) -------------------------------+-------------------------------------------- Reporter: TomMD | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: trivial Keywords: Foreign, Errno | Testcase: Architecture: Multiple | Os: Multiple -------------------------------+-------------------------------------------- Errno, the Haskell encapsulation of the CInt 'errno' value, should be an instance of the commonly used type classes so higher level data structures that include it aren't bothered. This change will break code that has custom instances for Errno, but this should be little, if any, code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 4 14:31:00 2008 From: trac at galois.com (GHC) Date: Sun May 4 14:25:19 2008 Subject: [GHC] #2262: Build failure of HEAD from 2008-05-04 on OS X 10.4.11 Message-ID: <047.3f0e3b88d9818643a9caa58f0fc62bf1@localhost> #2262: Build failure of HEAD from 2008-05-04 on OS X 10.4.11 -------------------------+-------------------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: blocker Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Build fails with the following error message {{{ Finished making all in runstdtest: 0 ------------------------------------------------------------------------ == make all -r; in /Users/nominolo/code/ghc/head/utils/ghc-pkg ------------------------------------------------------------------------ ../../compiler/stage1/ghc-inplace -no-user-package-conf -H64m -Onot -fasm -cpp -Wall -fno-warn-name-shadowing -fno-warn-unused-matches -package Cabal -Rghc-timing -O -fasm -package unix -package containers -c Version.hs -o Version.o -ohi Version.hi <> ../../compiler/stage1/ghc-inplace -no-user-package-conf -H64m -Onot -fasm -cpp -Wall -fno-warn-name-shadowing -fno-warn-unused-matches -package Cabal -Rghc-timing -O -fasm -package unix -package containers -c Main.hs -o Main.o -ohi Main.hi <> gcc -O -c CRT_noglob.c -o CRT_noglob.o ../../compiler/stage1/ghc-inplace -no-user-package-conf -o ghc-pkg.bin -H64m -Onot -fasm -cpp -Wall -fno-warn-name-shadowing -fno-warn-unused- matches -package Cabal -Rghc-timing -O -fasm -package unix -package containers Main.o Version.o CRT_noglob.o /usr/bin/ld: /Users/nominolo/code/ghc/head/rts/libHSrts.a(PrimOps.o) has external relocation entries in non-writable section (__TEXT,__text) for symbols: ___gmpn_cmp ___gmpn_gcd_1 ___gmpz_fdiv_qr ___gmpz_tdiv_qr ___gmpz_com ___gmpz_init ___gmpz_xor ___gmpz_ior ___gmpz_and ___gmpz_divexact ___gmpz_tdiv_r ___gmpz_tdiv_q ___gmpz_gcd ___gmpz_mul ___gmpz_sub ___gmpz_add collect2: ld returned 1 exit status <> make[3]: *** [ghc-pkg.bin] Error 1 Failed making all in ghc-pkg: 1 make[2]: *** [all] Error 1 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 }}} Version: 6.9.20080504 {{{ $ uname -a Darwin intothevoid.local 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 }}} {{{ BuildFlavour = quickest }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 4 15:32:52 2008 From: trac at galois.com (GHC) Date: Sun May 4 15:27:11 2008 Subject: [GHC] #2263: GHC 6.8 (STABLE) branch build framework does not pass correctly CPPFLAGS/LDFLAGS env vars to subsequent configure scripts Message-ID: <046.23fe9035121b5553a5c8813359d72f0f@localhost> #2263: GHC 6.8 (STABLE) branch build framework does not pass correctly CPPFLAGS/LDFLAGS env vars to subsequent configure scripts ------------------------+--------------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Solaris ------------------------+--------------------------------------------------- hello, it seems that build framework is a little bit buggy, since it does not pass correctly CPPFLAGS and LDFLAGS environment variables to the subsequent configure calls. For example, I do have libreadline installed in not usual location and I would like to do this: export CPPFLAGS=-I/usr/local/ghc-reqs/include/ export LDFLAGS=-L/usr/local/ghc-reqs/lib/ ./configure --prefix=/usr/local/ghc-2008-05-04 ghc-reqs directory contains libreadline installation. The problem is that build invoked by `make' fails with: gmake[1]: Entering directory `/export/home/karel/darcs/ghc/libraries' rm -f -f stamp/configure.library.*.base base/unbuildable ( cd base && setup/Setup configure \ --enable-library-profiling --enable-split-objs \ --prefix=/NONEXISTANT \ --bindir=/NONEXISTANT \ --libdir=/NONEXISTANT \ --libsubdir='$pkgid' \ --libexecdir=/NONEXISTANT \ --datadir=/NONEXISTANT \ --docdir=/NONEXISTANT \ --htmldir=/NONEXISTANT \ --interfacedir=/NONEXISTANT \ --with-compiler=../../compiler/stage1/ghc-inplace \ --with-hc-pkg=../../utils/ghc-pkg/ghc-pkg-inplace \ --with-hsc2hs=../../utils/hsc2hs/hsc2hs-inplace \ --with-ld=/usr/bin/ld \ --haddock-options="--use-contents=../index.html \ --use-index=../doc-index.html" \ --prefix=/usr/local/ghc-2008-05-04 CPPFLAGS=-I/usr/local/ghc-reqs/include/ LDFLAGS=-L/usr/local/ghc-reqs/lib/ \ --configure-option=--with-cc=gcc ) \ && touch stamp/configure.library.build-profiling- splitting.base || touch base/unbuildable Setup: Errors: unexpected argument: CPPFLAGS=-I/usr/local/ghc-reqs/include/ unexpected argument: LDFLAGS=-L/usr/local/ghc-reqs/lib/ unexpected argument: --configure-option=--with-cc=gcc if ifBuildable/ifBuildable base; then \ cd base && \ cmp -s ../Makefile.local Makefile.local || cp ../Makefile.local .; \ mv GNUmakefile GNUmakefile.tmp; \ setup/Setup makefile -f GNUmakefile; \ cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp GNUmakefile; \ gmake -wr --jobserver-fds=3,4 -j && \ setup/Setup register --inplace; \ fi mv: cannot access GNUmakefile Setup: error reading dist/setup-config; run "setup configure" command? gmake[2]: Entering directory `/export/home/karel/darcs/ghc/libraries/base' gmake[2]: *** No targets specified and no makefile found. Stop. gmake[2]: Leaving directory `/export/home/karel/darcs/ghc/libraries/base' gmake[1]: *** [make.library.base] Error 2 gmake[1]: Leaving directory `/export/home/karel/darcs/ghc/libraries' gmake: *** [stage1] Error 2 Is there any known workaround for this issue? Thanks, Karel -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 4 15:57:19 2008 From: trac at galois.com (GHC) Date: Sun May 4 15:51:36 2008 Subject: [GHC] #2263: GHC 6.8 (STABLE) branch build framework does not pass correctly CPPFLAGS/LDFLAGS env vars to subsequent configure scripts In-Reply-To: <046.23fe9035121b5553a5c8813359d72f0f@localhost> References: <046.23fe9035121b5553a5c8813359d72f0f@localhost> Message-ID: <055.ce8db597162dd216f587f82f9cef2085@localhost> #2263: GHC 6.8 (STABLE) branch build framework does not pass correctly CPPFLAGS/LDFLAGS env vars to subsequent configure scripts -----------------------------+---------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Testcase: Architecture: x86 | Os: Solaris -----------------------------+---------------------------------------------- Changes (by judah): * status: new => closed * resolution: => worksforme Comment: You should be able to do this by configuring ghc with the following arguments: {{{ ./configure --with-readline-libraries=/usr/local/ghc-reqs/lib --with- readline-includes=/usr/local/ghc-reqs/include }}} (You may want to use `--with-gmp-includes` and `--with-gmp-libraries` as well.) Please reopen this ticket if the above does not work for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 4 16:19:48 2008 From: trac at galois.com (GHC) Date: Sun May 4 16:14:08 2008 Subject: [GHC] #2171: Parallel program crashes In-Reply-To: <042.91539dd5667f046cb861faa36a106615@localhost> References: <042.91539dd5667f046cb861faa36a106615@localhost> Message-ID: <051.2be13e4c03c7515dfa9c34bd08b4fc4f@localhost> #2171: Parallel program crashes ---------------------------------------------+------------------------------ Reporter: fed | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: critical | Resolution: Keywords: parallel, crash, race condition | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------------------+------------------------------ Comment (by judah): That patch fixes it for me in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 4 17:33:37 2008 From: trac at galois.com (GHC) Date: Sun May 4 17:27:50 2008 Subject: [GHC] #2264: Validate using ghc-6.4.1: 3 failures, 1 workaround, 1 fix Message-ID: <050.9517ae6a8909fd14ebd0a610f101a565@localhost> #2264: Validate using ghc-6.4.1: 3 failures, 1 workaround, 1 fix ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ----------------------------+----------------------------------------------- Using {{{ $ uname -a Linux linux 2.6.13-15-default #1 Tue Sep 13 14:56:15 UTC 2005 i686 i686 i386 GNU/Linux $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.4.1 }}} to validate a recent HEAD, I get the following error: {{{ /home/tn/tn/install/ghc-6.4.1/bin/ghc -Werror -H64m -Onot -fasm -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow- exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -O -fasm -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -c utils/Util.lhs -o stage1/utils/Util.o -ohi stage1/utils/Util.hi utils/Util.lhs:204:0: Warning: Pattern match(es) are non-exhaustive In the definition of `zipLazy': Patterns not matched: (_ : _) [] <> make[1]: *** [stage1/utils/Util.o] Error 1 make[1]: *** Waiting for unfinished jobs.... <> make: *** [stage1] Error 1 }}} Offhand, I was not able to find a correction to this problem that was also found acceptanble by the stage2 (GHC-6.9-ish) compiler, so I simply ended up working around by disabling warnings, as indicated in first of the attached patches. Which should not, I stress, be taken as my suggested solution, simply as a way of getting ahead with the validate. (I am sure that a suitable solution can be found by the appropriate experts, as needed.) In any case, with this workaround in place, I get: {{{ /home/tn/tn/install/ghc-6.4.1/bin/ghc -Werror -H64m -Onot -fasm -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow- exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -O -fasm -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -c basicTypes/OccName.lhs -o stage1/basicTypes/OccName.o -ohi stage1/basicTypes/OccName.hi basicTypes/OccName.lhs:86:0: Warning: Definition but no type signature for `isSymbol' <> make[1]: *** [stage1/basicTypes/OccName.o] Error 1 make[1]: *** Waiting for unfinished jobs.... <> make: *** [stage1] Error 1 }}} And this time, the attached patch that eliminates this warning could be found to be the actual solution to the problem. Unfortunately, even with the second patch in place, I get: {{{ /home/tn/tn/install/ghc-6.4.1/bin/ghc -Werror -H64m -Onot -fasm -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow- exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -O -fasm -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -c cmm/ZipDataflow.hs -o stage1/cmm/ZipDataflow.o -ohi stage1/cmm/ZipDataflow.hi cmm/ZipDataflow.hs:285:0: Contexts differ in length When matching the contexts of the signatures for fwd_pure_anal :: forall m l a. (DebugNodes m l, Outputable a) => PassName -> BlockEnv a -> ForwardTransfers m l a -> a -> Graph m l -> DFM a (ForwardFixedPoint m l a ()) forward_sol :: forall m l (g :: * -> * -> *) a. (DebugNodes m l, LastNode l, Outputable a) => (forall a. Fuel -> Maybe a -> Maybe a) -> (g m l -> DFM a (Graph m l)) -> RewritingDepth -> PassName -> BlockEnv a -> ForwardTransfers m l a -> ForwardRewrites m l a g -> a -> Graph m l -> Fuel -> DFM a (ForwardFixedPoint m l a (), Fuel) The signature contexts in a mutually recursive group should all be identical cmm/ZipDataflow.hs:309:19: GHC internal error: `a' is not in scope In the type signature: forw :: RewritingDepth -> PassName -> BlockEnv a -> ForwardTransfers m l a -> ForwardRewrites m l a g -> a -> Graph m l -> Fuel -> DFM a (ForwardFixedPoint m l a (), Fuel) In the definition of `forward_sol': forward_sol check_maybe return_graph = forw where forw :: RewritingDepth -> PassName -> BlockEnv a -> ForwardTransfers m l a -> ForwardRewrites m l a g -> a -> Graph m l -> Fuel -> DFM a (ForwardFixedPoint m l a (), Fuel) forw rewrite name start_facts transfers rewrites = let either_last rewrites in' (LastExit) = ... either_last rewrites in' (LastOther l) = ... anal_f :: DFM a b -> a -> Graph m l -> DFM a b anal_f finish in' g = ... solve :: DFM a b -> a -> Graph m l -> Fuel -> DFM a (b, Fuel) solve_tail in' (ZTail m t) fuel = ... solve_tail in' (ZLast l) fuel = ... solve finish in_fact (Graph entry blockenv) fuel = ... fixed_point in_fact g fuel = ... in fixed_point cmm/ZipDataflow.hs:317:21: GHC internal error: `a' is not in scope In the type signature: anal_f :: DFM a b -> a -> Graph m l -> DFM a b In the definition of `forw': forw rewrite name start_facts transfers rewrites = let either_last rewrites in' (LastExit) = fr_exit rewrites in' either_last rewrites in' (LastOther l) = fr_last rewrites in' l anal_f :: DFM a b -> a -> Graph m l -> DFM a b anal_f finish in' g = do ... ... solve :: DFM a b -> a -> Graph m l -> Fuel -> DFM a (b, Fuel) solve_tail in' (ZTail m t) fuel = case ... of Nothing -> ... Just g -> ... solve_tail in' (ZLast l) fuel = case ... of Nothing -> ... Just g -> ... solve finish in_fact (Graph entry blockenv) fuel = let ... in ... fixed_point in_fact g fuel = do ... (a, fuel) <- ... facts <- ... last_outs <- ... let ... let ... ... in fixed_point In the definition of `forward_sol': forward_sol check_maybe return_graph = forw where forw :: RewritingDepth -> PassName -> BlockEnv a -> ForwardTransfers m l a -> ForwardRewrites m l a g -> a -> Graph m l -> Fuel -> DFM a (ForwardFixedPoint m l a (), Fuel) forw rewrite name start_facts transfers rewrites = let either_last rewrites in' (LastExit) = ... either_last rewrites in' (LastOther l) = ... anal_f :: DFM a b -> a -> Graph m l -> DFM a b anal_f finish in' g = ... solve :: DFM a b -> a -> Graph m l -> Fuel -> DFM a (b, Fuel) solve_tail in' (ZTail m t) fuel = ... solve_tail in' (ZLast l) fuel = ... solve finish in_fact (Graph entry blockenv) fuel = ... fixed_point in_fact g fuel = ... in fixed_point cmm/ZipDataflow.hs:321:20: GHC internal error: `a' is not in scope In the type signature: solve :: DFM a b -> a -> Graph m l -> Fuel -> DFM a (b, Fuel) In the definition of `forw': forw rewrite name start_facts transfers rewrites = let either_last rewrites in' (LastExit) = fr_exit rewrites in' either_last rewrites in' (LastOther l) = fr_last rewrites in' l anal_f :: DFM a b -> a -> Graph m l -> DFM a b anal_f finish in' g = do ... ... solve :: DFM a b -> a -> Graph m l -> Fuel -> DFM a (b, Fuel) solve_tail in' (ZTail m t) fuel = case ... of Nothing -> ... Just g -> ... solve_tail in' (ZLast l) fuel = case ... of Nothing -> ... Just g -> ... solve finish in_fact (Graph entry blockenv) fuel = let ... in ... fixed_point in_fact g fuel = do ... (a, fuel) <- ... facts <- ... last_outs <- ... let ... let ... ... in fixed_point In the definition of `forward_sol': forward_sol check_maybe return_graph = forw where forw :: RewritingDepth -> PassName -> BlockEnv a -> ForwardTransfers m l a -> ForwardRewrites m l a g -> a -> Graph m l -> Fuel -> DFM a (ForwardFixedPoint m l a (), Fuel) forw rewrite name start_facts transfers rewrites = let either_last rewrites in' (LastExit) = ... either_last rewrites in' (LastOther l) = ... anal_f :: DFM a b -> a -> Graph m l -> DFM a b anal_f finish in' g = ... solve :: DFM a b -> a -> Graph m l -> Fuel -> DFM a (b, Fuel) solve_tail in' (ZTail m t) fuel = ... solve_tail in' (ZLast l) fuel = ... solve finish in_fact (Graph entry blockenv) fuel = ... fixed_point in_fact g fuel = ... in fixed_point cmm/ZipDataflow.hs:371:43: Occurs check: cannot construct the infinite type: f = LastOutFacts f Expected type: DFM f f Inferred type: DFM f (LastOutFacts f) In the first argument of `solve', namely `lastOutFacts' In a case alternative: RewriteDeep -> solve lastOutFacts in' g (oneLessFuel fuel) cmm/ZipDataflow.hs:497:64: Couldn't match the rigid variable `a' against `()' `a' is bound by the type signature for `forward_rew' Expected type: a Inferred type: () In the first argument of `return', namely `()' In the first argument of `inner_rew', namely `(return ())' cmm/ZipDataflow.hs:584:19: GHC internal error: `a' is not in scope In the type signature: back :: RewritingDepth -> PassName -> BlockEnv a -> BackwardTransfers m l a -> BackwardRewrites m l a g -> Graph m l -> a -> Fuel -> DFM a (BackwardFixedPoint m l a (), Fuel) In the definition of `backward_sol': backward_sol check_maybe return_graph = back where back :: RewritingDepth -> PassName -> BlockEnv a -> BackwardTransfers m l a -> BackwardRewrites m l a g -> Graph m l -> a -> Fuel -> DFM a (BackwardFixedPoint m l a (), Fuel) back rewrite name start_facts transfers rewrites = let anal_b :: Graph m l -> a -> DFM a a anal_b g out = ... subsolve :: g m l -> a -> Fuel -> DFM a (a, Fuel) solve :: Graph m l -> a -> Fuel -> DFM a (a, Fuel) subsolve = ... solve (Graph entry blockenv) exit_fact fuel = ... set_head_fact (ZFirst id) a fuel = ... set_head_fact (ZHead h m) a fuel = ... fixed_point g exit_fact fuel = ... in fixed_point cmm/ZipDataflow.hs:592:23: GHC internal error: `m' is not in scope In the type signature: anal_b :: Graph m l -> a -> DFM a a In the definition of `back': back rewrite name start_facts transfers rewrites = let anal_b :: Graph m l -> a -> DFM a a anal_b g out = do fp <- ... ... subsolve :: g m l -> a -> Fuel -> DFM a (a, Fuel) solve :: Graph m l -> a -> Fuel -> DFM a (a, Fuel) subsolve = case ... of RewriteDeep -> ... RewriteShallow -> ... solve (Graph entry blockenv) exit_fact fuel = let ... in ... set_head_fact (ZFirst id) a fuel = case ... of Nothing -> ... Just g -> ... set_head_fact (ZHead h m) a fuel = case ... of Nothing -> ... Just g -> ... fixed_point g exit_fact fuel = do ... (a, fuel) <- ... facts <- ... let ... ... in fixed_point In the definition of `backward_sol': backward_sol check_maybe return_graph = back where back :: RewritingDepth -> PassName -> BlockEnv a -> BackwardTransfers m l a -> BackwardRewrites m l a g -> Graph m l -> a -> Fuel -> DFM a (BackwardFixedPoint m l a (), Fuel) back rewrite name start_facts transfers rewrites = let anal_b :: Graph m l -> a -> DFM a a anal_b g out = ... subsolve :: g m l -> a -> Fuel -> DFM a (a, Fuel) solve :: Graph m l -> a -> Fuel -> DFM a (a, Fuel) subsolve = ... solve (Graph entry blockenv) exit_fact fuel = ... set_head_fact (ZFirst id) a fuel = ... set_head_fact (ZHead h m) a fuel = ... fixed_point g exit_fact fuel = ... in fixed_point cmm/ZipDataflow.hs:597:19: GHC internal error: `g' is not in scope In the type signature: subsolve :: g m l -> a -> Fuel -> DFM a (a, Fuel) In the definition of `back': back rewrite name start_facts transfers rewrites = let anal_b :: Graph m l -> a -> DFM a a anal_b g out = do fp <- ... ... subsolve :: g m l -> a -> Fuel -> DFM a (a, Fuel) solve :: Graph m l -> a -> Fuel -> DFM a (a, Fuel) subsolve = case ... of RewriteDeep -> ... RewriteShallow -> ... solve (Graph entry blockenv) exit_fact fuel = let ... in ... set_head_fact (ZFirst id) a fuel = case ... of Nothing -> ... Just g -> ... set_head_fact (ZHead h m) a fuel = case ... of Nothing -> ... Just g -> ... fixed_point g exit_fact fuel = do ... (a, fuel) <- ... facts <- ... let ... ... in fixed_point In the definition of `backward_sol': backward_sol check_maybe return_graph = back where back :: RewritingDepth -> PassName -> BlockEnv a -> BackwardTransfers m l a -> BackwardRewrites m l a g -> Graph m l -> a -> Fuel -> DFM a (BackwardFixedPoint m l a (), Fuel) back rewrite name start_facts transfers rewrites = let anal_b :: Graph m l -> a -> DFM a a anal_b g out = ... subsolve :: g m l -> a -> Fuel -> DFM a (a, Fuel) solve :: Graph m l -> a -> Fuel -> DFM a (a, Fuel) subsolve = ... solve (Graph entry blockenv) exit_fact fuel = ... set_head_fact (ZFirst id) a fuel = ... set_head_fact (ZHead h m) a fuel = ... fixed_point g exit_fact fuel = ... in fixed_point cmm/ZipDataflow.hs:653:0: Contexts differ in length When matching the contexts of the signatures for backward_sol :: forall m l (g :: * -> * -> *) a. (DebugNodes m l, LastNode l, Outputable a) => (forall a. Fuel -> Maybe a -> Maybe a) -> (g m l -> DFM a (Graph m l)) -> RewritingDepth -> PassName -> BlockEnv a -> BackwardTransfers m l a -> BackwardRewrites m l a g -> Graph m l -> a -> Fuel -> DFM a (CommonFixedPoint m l a (), Fuel) bwd_pure_anal :: forall m l a. (DebugNodes m l, Outputable a) => PassName -> BlockEnv a -> BackwardTransfers m l a -> Graph m l -> a -> DFM a (CommonFixedPoint m l a ()) The signature contexts in a mutually recursive group should all be identical <> make[1]: *** [stage1/cmm/ZipDataflow.o] Error 1 make[1]: *** Waiting for unfinished jobs.... <> make: *** [stage1] Error 1 }}} And that is the state of affairs as I report this. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 5 02:19:58 2008 From: trac at galois.com (GHC) Date: Mon May 5 02:14:27 2008 Subject: [GHC] #2263: GHC 6.8 (STABLE) branch build framework does not pass correctly CPPFLAGS/LDFLAGS env vars to subsequent configure scripts In-Reply-To: <046.23fe9035121b5553a5c8813359d72f0f@localhost> References: <046.23fe9035121b5553a5c8813359d72f0f@localhost> Message-ID: <055.d0a45a779ecbe4a65a2268595802d6bf@localhost> #2263: GHC 6.8 (STABLE) branch build framework does not pass correctly CPPFLAGS/LDFLAGS env vars to subsequent configure scripts -----------------------------+---------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Solaris -----------------------------+---------------------------------------------- Changes (by kgardas): * status: closed => reopened * resolution: worksforme => Comment: Hello, the problem is that with your suggested --with-readline-* options, build fails even more early: gmake[1]: Entering directory `/export/home/karel/darcs/ghc/libraries' rm -f -f stamp/configure.library.*.base base/unbuildable ( cd base && setup/Setup configure \ --enable-library-profiling --enable-split-objs \ --prefix=/NONEXISTANT \ --bindir=/NONEXISTANT \ --libdir=/NONEXISTANT \ --libsubdir='$pkgid' \ --libexecdir=/NONEXISTANT \ --datadir=/NONEXISTANT \ --docdir=/NONEXISTANT \ --htmldir=/NONEXISTANT \ --interfacedir=/NONEXISTANT \ --with-compiler=../../compiler/stage1/ghc-inplace \ --with-hc-pkg=../../utils/ghc-pkg/ghc-pkg-inplace \ --with-hsc2hs=../../utils/hsc2hs/hsc2hs-inplace \ --with-ld=/usr/bin/ld \ --haddock-options="--use-contents=../index.html \ --use-index=../doc-index.html" \ --prefix=/usr/local/ghc-2008-05-04 --with-readline- libraries=/usr/local/ghc-reqs/lib/ --with-readline-includes=/usr/local /ghc-reqs/include/ \ --configure-option=--with-cc=gcc ) \ && touch stamp/configure.library.build-profiling- splitting.base || touch base/unbuildable Setup: Unrecognised flags: --with-readline-libraries=/usr/local/ghc-reqs/lib/ --with-readline-includes=/usr/local/ghc-reqs/include/ if ifBuildable/ifBuildable base; then \ cd base && \ cmp -s ../Makefile.local Makefile.local || cp ../Makefile.local .; \ mv GNUmakefile GNUmakefile.tmp; \ setup/Setup makefile -f GNUmakefile; \ cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp GNUmakefile; \ gmake -wr && \ setup/Setup register --inplace; \ fi mv: cannot access GNUmakefile Setup: error reading dist/setup-config; run "setup configure" command? gmake[2]: Entering directory `/export/home/karel/darcs/ghc/libraries/base' gmake[2]: *** No targets specified and no makefile found. Stop. gmake[2]: Leaving directory `/export/home/karel/darcs/ghc/libraries/base' gmake[1]: *** [make.library.base] Error 2 gmake[1]: Leaving directory `/export/home/karel/darcs/ghc/libraries' gmake: *** [stage1] Error 2 BTW: I'm using recommended autoconf 2.52/automake 1.9. I'm curious how have you been able to pass thorough this issue. Thanks, Karel -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 5 04:25:47 2008 From: trac at galois.com (GHC) Date: Mon May 5 04:20:09 2008 Subject: [GHC] #2265: GHC 6.8 (STABLE) autoconf version requirements issue Message-ID: <046.cca200a2c8f3c0dc4698eeb862b6f329@localhost> #2265: GHC 6.8 (STABLE) autoconf version requirements issue ------------------------+--------------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Solaris ------------------------+--------------------------------------------------- Hello, I'm trying to build GHC stable on Solaris/x86 (Solaris Express Developer Edition 1/08 exactly) and after end-less of loops and attempts I tried to experiment with various autoconf versions since my issues was all build issues where autoconf was involved. So at least partial conclusion is that autoconf 2.52 cannot be used nor autoconf 2.62. Both produce configure scripts which are not able to build GHC. Finally when I tried autoconf 2.59 I've been successful and build works for the first time. I'm writing this bug to point this out and ask for correction of this page http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites Thanks! Karel -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 5 04:28:06 2008 From: trac at galois.com (GHC) Date: Mon May 5 04:22:21 2008 Subject: [GHC] #2263: GHC 6.8 (STABLE) branch build framework does not pass correctly CPPFLAGS/LDFLAGS env vars to subsequent configure scripts In-Reply-To: <046.23fe9035121b5553a5c8813359d72f0f@localhost> References: <046.23fe9035121b5553a5c8813359d72f0f@localhost> Message-ID: <055.091cc9ff16c7bd4ab15f252fa5bc7a70@localhost> #2263: GHC 6.8 (STABLE) branch build framework does not pass correctly CPPFLAGS/LDFLAGS env vars to subsequent configure scripts -----------------------------+---------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Solaris -----------------------------+---------------------------------------------- Comment (by kgardas): Hello, you might close this bug since this seems to be autoconf 2.52 issue. I've already filled different bug report: http://hackage.haskell.org/trac/ghc/ticket/2265 which points this out. Thanks! Karel -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 5 05:54:42 2008 From: trac at galois.com (GHC) Date: Mon May 5 05:48:55 2008 Subject: [GHC] #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs In-Reply-To: <046.59221d2fec02e33b156d46e404241b5d@localhost> References: <046.59221d2fec02e33b156d46e404241b5d@localhost> Message-ID: <055.8a4b88f7ffefddced7985dc34dbbe9e4@localhost> #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs ----------------------+----------------------------------------------------- Reporter: oboudry | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: OK, thanks for the reply! No other opinions, so I'll close the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 5 05:57:19 2008 From: trac at galois.com (GHC) Date: Mon May 5 05:51:35 2008 Subject: [GHC] #2171: Parallel program crashes In-Reply-To: <042.91539dd5667f046cb861faa36a106615@localhost> References: <042.91539dd5667f046cb861faa36a106615@localhost> Message-ID: <051.f90d6df29ca991b3204b9c72b2054c33@localhost> #2171: Parallel program crashes ---------------------------------------------+------------------------------ Reporter: fed | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: critical | Resolution: fixed Keywords: parallel, crash, race condition | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------------------+------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks judah; that patch is already merged, so I'll close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 5 06:03:59 2008 From: trac at galois.com (GHC) Date: Mon May 5 05:58:11 2008 Subject: [GHC] #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs In-Reply-To: <046.59221d2fec02e33b156d46e404241b5d@localhost> References: <046.59221d2fec02e33b156d46e404241b5d@localhost> Message-ID: <055.f8496a9d206ed0dd7af29d3c968667ab@localhost> #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs ----------------------+----------------------------------------------------- Reporter: oboudry | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by NeilMitchell): * status: closed => reopened * cc: ndmitchell@gmail.com (added) * resolution: invalid => Comment: The executable extensions are given by the environment variable %PATHEXT%. On Vista: PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC I'm not entirely convinced GHC is doing the right thing here though. I think there are two entirely separate cases which are being treated equivalently: 1) Not specifying -o. ghc --make .hs should create ".exe". Even ghc --make Main.exe.hs should create Main.exe.exe. This fixes this bug in a clean way, without knowledge of which extensions are executable. 2) Specifying -o. ghc -o should create .exe unless name already has an extension. i.e. -o foo.123 produces foo.123, but -o foo produces foo.exe. This maintains existing behaviour. I suspect this is being implemented as ghc --make .hs is translated to ghc --make .hs -o , which is merging the behaviour of the two cases, and getting the first case (in this bug) wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 5 08:43:57 2008 From: trac at galois.com (GHC) Date: Mon May 5 08:38:10 2008 Subject: [GHC] #1467: GHC API: expose separate compilation stages In-Reply-To: <047.d7c1a2808de3a4b26cf0a0e5a5797905@localhost> References: <047.d7c1a2808de3a4b26cf0a0e5a5797905@localhost> Message-ID: <056.44d5fce6d47dec4e3919c9dd0068c5a0@localhost> #1467: GHC API: expose separate compilation stages ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: nominolo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by nominolo): * owner: => nominolo * version: 6.6.1 => 6.9 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 5 09:57:17 2008 From: trac at galois.com (GHC) Date: Mon May 5 09:51:36 2008 Subject: [GHC] #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs In-Reply-To: <046.59221d2fec02e33b156d46e404241b5d@localhost> References: <046.59221d2fec02e33b156d46e404241b5d@localhost> Message-ID: <055.30aeda761d5bf73e83a0790a6be99d6d@localhost> #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs ----------------------+----------------------------------------------------- Reporter: oboudry | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Comment (by oboudry): I agree with Neil on #1. Not specifying -o on Win32 should always append the .exe extension. I don't think people would "code" the extension in the file name (I may be wrong). On case #2 it looks like GHC already does what Neil specified and that works fine for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 5 10:39:54 2008 From: trac at galois.com (GHC) Date: Mon May 5 10:34:05 2008 Subject: [GHC] #2264: Validate using ghc-6.4.1: 3 failures, 1 workaround, 1 fix In-Reply-To: <050.9517ae6a8909fd14ebd0a610f101a565@localhost> References: <050.9517ae6a8909fd14ebd0a610f101a565@localhost> Message-ID: <059.a76ec3d2ed5724140cdd1db4fc128f19@localhost> #2264: Validate using ghc-6.4.1: 3 failures, 1 workaround, 1 fix -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks Thorkil. I think that `zipLazy` could be rewritten as {{{ zipLazy [] _ = [] zipLazy (x:xs) zs = let y : ys = zs in (x,y) : zipLazy xs ys }}} (although I haven't tested it with 6.4), but before fixing that, I'd like to know what our plan is for the `ZipDataflow` problems. I suspect that the problem is that it uses scoped type variables, and the syntax and semantics of those have changed quite a bit. We really probably only have 2 options: declare that 6.10 needs >= 6.6 to build, or rewrite the code not to use scoped type variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From nr at eecs.harvard.edu Mon May 5 13:37:48 2008 From: nr at eecs.harvard.edu (Norman Ramsey) Date: Mon May 5 13:32:00 2008 Subject: [GHC] #2257: validate hangs in configure In-Reply-To: <050.a18c8be071f12d8f39306b7fe6a5bf85@localhost> (sfid-H-20080503-140656-+26.70-1@multi.osbf.lua) References: <041.16fba6c404adcf566b7f71a6b9078150@localhost> <050.a18c8be071f12d8f39306b7fe6a5bf85@localhost> (sfid-H-20080503-140656-+26.70-1@multi.osbf.lua) Message-ID: <20080505173750.34EE7E803E@jindo.eecs.harvard.edu> > #2257: validate hangs in configure > Can you attach the exact program (using nanosleep) that's being run, and > the command line used to build and run it please? Done. > And can you check that `timer_delete` succeeds (it should return 0). No time; have to run to an appointment. N From trac at galois.com Mon May 5 15:37:19 2008 From: trac at galois.com (GHC) Date: Mon May 5 15:31:30 2008 Subject: [GHC] #2264: Validate using ghc-6.4.1: 3 failures, 1 workaround, 1 fix In-Reply-To: <050.9517ae6a8909fd14ebd0a610f101a565@localhost> References: <050.9517ae6a8909fd14ebd0a610f101a565@localhost> Message-ID: <059.358febd8c1e18044a10d4d88c412c316@localhost> #2264: Validate using ghc-6.4.1: 3 failures, 1 workaround, 1 fix -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Comment (by thorkilnaur): Replying to [comment:1 igloo]: Thanks Ian, your suggested zipLazy compiles with GHC-6.4.1. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 5 15:49:34 2008 From: trac at galois.com (GHC) Date: Mon May 5 15:43:44 2008 Subject: [GHC] #2266: validate requires haddock to be installed Message-ID: <050.c15637911c8b86321b0fb91e30218ecb@localhost> #2266: validate requires haddock to be installed ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ----------------------------+----------------------------------------------- A validate of a recent GHC HEAD on a machine that didn't have haddock installed ended with the report: {{{ if ifBuildable/ifBuildable ghc-prim; then \ cd ghc-prim && setup/Setup haddock --html-location='../$pkg' \ ; \ fi Setup: haddock version >=0.6 is required but it could not be found. make[1]: *** [doc.library.ghc-prim] Error 1 make[1]: Leaving directory `/usr/home/tn/tn/GHCDarcsRepository/ghc-HEAD- complete-20080503_0226/ghc/libraries' make: *** [stage1] Error 2 }}} This requirement is not mentioned on http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites and ought, if kept, to be checked and reported in the initial configure phase. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 6 03:20:31 2008 From: trac at galois.com (GHC) Date: Tue May 6 03:14:49 2008 Subject: [GHC] #2243: Can we remove IlxGen, Java, JavaGen, PrintJava? In-Reply-To: <048.1c657e7d878b9e4b4af84a238ffbca14@localhost> References: <048.1c657e7d878b9e4b4af84a238ffbca14@localhost> Message-ID: <057.39b7d4ba791a61b4e746a7c054f0f0d2@localhost> #2243: Can we remove IlxGen, Java, JavaGen, PrintJava? --------------------------+------------------------------------------------- Reporter: MarcWeber | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Comment (by simonpj): Yes, I think we can remove `IlxGen`, `Java`, `JavaGen` and `PrintJava`. I don't think they've been touched in 5 yrs, and they are still in the repo if anyone wants to recover them Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 6 05:57:13 2008 From: trac at galois.com (GHC) Date: Tue May 6 05:51:31 2008 Subject: [GHC] #2246: Numeric literal very badly optimized In-Reply-To: <044.ea64e9326ad25932314b8864281b1a7d@localhost> References: <044.ea64e9326ad25932314b8864281b1a7d@localhost> Message-ID: <053.8657d1a09d014cbcc84ab3adaeb6efb3@localhost> #2246: Numeric literal very badly optimized ----------------------+----------------------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 6 06:25:07 2008 From: trac at galois.com (GHC) Date: Tue May 6 06:19:16 2008 Subject: [GHC] #2267: Bogus "unused import" warning Message-ID: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> #2267: Bogus "unused import" warning -------------------------+-------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- In `DsMeta` (in the source code for GHC itself), there's an import {{{ import qualified OccName }}} With `-fwarn-unused-imports` we get the warning {{{ deSugar/DsMeta.hs:45:0: Warning: Module `OccName' is imported, but nothing from it is used, except perhaps instances visible in `OccName' To suppress this warning, use: import OccName() }}} But that's wrong: there are several uses of things imported from `OccName`. I tried to reproduce this in a much smaller program, and failed, so something not entirely trivial is happening. Hence this ticket, to make sure we don't forget. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 6 06:33:22 2008 From: trac at galois.com (GHC) Date: Tue May 6 06:27:30 2008 Subject: [GHC] #1074: -fwarn-unused-imports complains about wrong import In-Reply-To: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> References: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> Message-ID: <053.d8b129421b14c37db9f9e10f6e53a2d5@localhost> #1074: -fwarn-unused-imports complains about wrong import ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Comment (by igloo): Here's the behaviour I'd like: For each use of a variable foo, mark imports {{{ import M (..., foo, ...) }}} as "used" if any exist; otherwise mark any imports {{{ import M }}} which export foo as "used". Mark all imports of the form {{{ import M () }}} as used. Then warn about any imports not marked as "used". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 6 06:33:56 2008 From: trac at galois.com (GHC) Date: Tue May 6 06:28:04 2008 Subject: [GHC] #2267: Bogus "unused import" warning In-Reply-To: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> References: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> Message-ID: <055.9c248a1e4e0e174fda52995f65c0c94d@localhost> #2267: Bogus "unused import" warning ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): I haven't checked, but I assume it's another example of #1074. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 6 06:34:04 2008 From: trac at galois.com (GHC) Date: Tue May 6 06:28:14 2008 Subject: [GHC] #1074: -fwarn-unused-imports complains about wrong import In-Reply-To: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> References: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> Message-ID: <053.28ff7e40e1fd2df1b84b40d8c74b8e4c@localhost> #1074: -fwarn-unused-imports complains about wrong import ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Comment (by igloo): See also #2267. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 6 06:35:26 2008 From: trac at galois.com (GHC) Date: Tue May 6 06:29:41 2008 Subject: [GHC] #2246: Numeric literal very badly optimized In-Reply-To: <044.ea64e9326ad25932314b8864281b1a7d@localhost> References: <044.ea64e9326ad25932314b8864281b1a7d@localhost> Message-ID: <053.d07d01bfb3232b76dbdd78367d5fead2@localhost> #2246: Numeric literal very badly optimized ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Tue May 6 03:25:51 PDT 2008 simonpj@microsoft.com * Fix Trac #2246; overhaul handling of overloaded literals }}} I'm not sure this is worth propagating to the 6.8 branch; maybe worth it if it goes over cleanly. I don't know how to make a test for this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 6 06:38:49 2008 From: trac at galois.com (GHC) Date: Tue May 6 06:32:57 2008 Subject: [GHC] #2264: Validate using ghc-6.4.1: 3 failures, 1 workaround, 1 fix In-Reply-To: <050.9517ae6a8909fd14ebd0a610f101a565@localhost> References: <050.9517ae6a8909fd14ebd0a610f101a565@localhost> Message-ID: <059.3d3ddd228c55c47e1112a9e0c082f790@localhost> #2264: Validate using ghc-6.4.1: 3 failures, 1 workaround, 1 fix -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Comment (by simonpj): Concerning `ZipDataFlow`, it's nothing to do with scoped type variables, happily. As the error message says, in H98, the context of type sigs in a mutual rec group must be identical. I've pushed a patch that should fix it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 6 09:44:58 2008 From: trac at galois.com (GHC) Date: Tue May 6 09:39:06 2008 Subject: [GHC] #1874: getDirectoryContents yields "invalid argument" instead of "permission error" In-Reply-To: <044.aea88e13611e8c8d6805f551748c45bd@localhost> References: <044.aea88e13611e8c8d6805f551748c45bd@localhost> Message-ID: <053.3a4079a96ba6df692284ab3c9148cb25@localhost> #1874: getDirectoryContents yields "invalid argument" instead of "permission error" ------------------------------------------------------------------+--------- Reporter: Orphi | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.8.3 Component: libraries/directory | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: getDirectoryContents "C:\\System Volume Information" | Architecture: x86 Os: Windows | ------------------------------------------------------------------+--------- Comment (by Deewiant): What version of Windows are you using? This is on Windows XP Professional with Service Pack 2: {{{ $ cat asdf.hs module Main (main) where import Control.Exception import Prelude hiding (catch) import System.Directory main :: IO () main = do (getDirectoryContents "D:\\Main\\npd" >> return ()) `catch` print putStrLn "Foo" }}} {{{ $ ls -ld npd d---------+ 2 Deewiant None 0 May 6 16:34 npd }}} {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 }}} {{{ $ ghc --make -fforce-recomp asdf [1 of 1] Compiling Main ( asdf.hs, asdf.o ) Linking asdf.exe ... }}} {{{ $ ./asdf.exe D:\Main\npd: getDirectoryContents: invalid argument (Invalid argument) Foo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 6 12:03:21 2008 From: trac at galois.com (GHC) Date: Tue May 6 11:57:29 2008 Subject: [GHC] #2268: ghci "*** Exception: expectJust upseep1" Message-ID: <044.b080eb3ed27d95c0472e4d8e60e84999@localhost> #2268: ghci "*** Exception: expectJust upseep1" -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- ghci gets confused, reporting "*** Exception: expectJust upseep1". I think it's related to having pre-compiled source files that cyclicly import each other, but havn't double checked/proven it. Trace to reproduce the bug here: (notice that at the start Simplify.hs has a bug in it, and after loading it, but before doing :!cat Simplify.hs I have fixed the error in Simplify.hs) {{{ 16:56:38 - tora@colorado:/tmp/GhcBug.hs >ls Bookmarks.hs Bookmarks.hs-boot Cursor.hs Simplify.hs 16:56:51 - tora@colorado:/tmp/GhcBug.hs >ghc --make -c Cursor.hs Bookmarks.hs [1 of 3] Compiling Bookmarks[boot] ( Bookmarks.hs-boot, Bookmarks.o-boot ) [2 of 3] Compiling Cursor ( Cursor.hs, Cursor.o ) [3 of 3] Compiling Bookmarks ( Bookmarks.hs, Bookmarks.o ) 16:57:05 - tora@colorado:/tmp/GhcBug.hs >cat Simplify.hs module HExp.Simplify where import Cursor(Cursor) iterateMaybe :: (a -> Maybe a) -> a -> [a] iterateMaybe f init = init : maybe [] (iterateMaybe) (f init) 16:57:20 - tora@colorado:/tmp/GhcBug.hs >ghci Simplify.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [3 of 4] Compiling HExp.Simplify ( Simplify.hs, interpreted ) Simplify.hs:6:39: Couldn't match expected type `[a]' against inferred type `a1 -> [a1]' Probable cause: `iterateMaybe' is applied to too few arguments In the second argument of `maybe', namely `(iterateMaybe)' In the second argument of `(:)', namely `maybe [] (iterateMaybe) (f init)' Failed, modules loaded: Cursor, Bookmarks, Bookmarks. Prelude Bookmarks> :!cat Simplify.hs module HExp.Simplify where import Cursor(Cursor) iterateMaybe :: (a -> Maybe a) -> a -> [a] iterateMaybe f init = init : maybe [] (iterateMaybe f) (f init) Prelude Bookmarks> :r *** Exception: expectJust upseep1 > Leaving GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 6 12:35:19 2008 From: trac at galois.com (GHC) Date: Tue May 6 12:29:33 2008 Subject: [GHC] #2243: Can we remove IlxGen, Java, JavaGen, PrintJava? In-Reply-To: <048.1c657e7d878b9e4b4af84a238ffbca14@localhost> References: <048.1c657e7d878b9e4b4af84a238ffbca14@localhost> Message-ID: <057.0426afcdb8e71e2f6333e1eb17b1c310@localhost> #2243: Can we remove IlxGen, Java, JavaGen, PrintJava? --------------------------+------------------------------------------------- Reporter: MarcWeber | Owner: Type: task | Status: closed Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Great, they're now gone! -- Ticket URL: GHC The Glasgow Haskell Compiler From dons at galois.com Tue May 6 13:18:59 2008 From: dons at galois.com (Don Stewart) Date: Tue May 6 13:13:11 2008 Subject: [GHC] #2243: Can we remove IlxGen, Java, JavaGen, PrintJava? In-Reply-To: <057.0426afcdb8e71e2f6333e1eb17b1c310@localhost> References: <048.1c657e7d878b9e4b4af84a238ffbca14@localhost> <057.0426afcdb8e71e2f6333e1eb17b1c310@localhost> Message-ID: <20080506171859.GA2246@scytale.galois.com> trac: > #2243: Can we remove IlxGen, Java, JavaGen, PrintJava? > --------------------------+------------------------------------------------- > Reporter: MarcWeber | Owner: > Type: task | Status: closed > Priority: normal | Milestone: 6.10 branch > Component: Build System | Version: 6.8.2 > Severity: minor | Resolution: fixed > Keywords: | Difficulty: Unknown > Testcase: | Architecture: Unknown > Os: Unknown | > --------------------------+------------------------------------------------- > Changes (by igloo): > > * status: new => closed > * resolution: => fixed > > Comment: > > Great, they're now gone! Yay! From trac at galois.com Wed May 7 06:47:33 2008 From: trac at galois.com (GHC) Date: Wed May 7 06:41:42 2008 Subject: [GHC] #1968: data family + GADT: not implemented yet In-Reply-To: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> References: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> Message-ID: <052.5f935ea1d147c2620d97a3dafcaec588@localhost> #1968: data family + GADT: not implemented yet ------------------------------------------------+--------------------------- Reporter: Remi | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: data type family GADT choose_univs | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ------------------------------------------------+--------------------------- Changes (by guest): * cc: tora@zonetora.co.uk (added) Comment: Also interested in this. Will the implementation allow varying non- instance types? {{{ {-# LANGUAGE TypeFamilies, KindSignatures, GADTs #-} module Foo2 where data family Blah x :: * -> * data instance Blah Bool where Bool1 :: Blah Bool Int Bool2 :: Blah Bool Char data instance Blah Char where Char1 :: Blah Char Int Char2 :: Blah Char Char }}} {{{ >ghc-6.9.20080401 -c Foo2.hs ghc-6.9.20080401: panic! (the 'impossible' happened) (GHC version 6.9.20080401 for x86_64-unknown-linux): typecheck/TcTyClsDecls.lhs:(883,4)-(889,42): Non-exhaustive patterns in function choose_univs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 7 08:25:54 2008 From: trac at galois.com (GHC) Date: Wed May 7 08:20:03 2008 Subject: [GHC] #2250: unpackFamily on Windows 2008 fails match In-Reply-To: <044.9136a0e7b8ebc803db4744ef0ab955c3@localhost> References: <044.9136a0e7b8ebc803db4744ef0ab955c3@localhost> Message-ID: <053.067b75b0b05b8923f214ac4f9d1a58d7@localhost> #2250: unpackFamily on Windows 2008 fails match -------------------------------+-------------------------------------------- Reporter: larsv | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -------------------------------+-------------------------------------------- Comment (by larsv): I modified Network/BSD.hs to trace out the h_addrtype variable in Storable HostEntry's peek, and it had the value 0x40002. The corresponding variable in the C struct should be a short, but is inferred to be CInt in the Haskell source, probably thanks to unpackFamily having type CInt -> Family. Due to that, it reads the family as an int, consuming the following length field as well. I hacked past this by giving the peek of h_addrtype an annotation of ":: IO CShort" and adding a fromIntegral at the call to unpackFamily to convert it to the CInt that the unpackFamily function expects. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 7 09:13:47 2008 From: trac at galois.com (GHC) Date: Wed May 7 09:07:52 2008 Subject: [GHC] #2250: unpackFamily on Windows 2008 fails match In-Reply-To: <044.9136a0e7b8ebc803db4744ef0ab955c3@localhost> References: <044.9136a0e7b8ebc803db4744ef0ab955c3@localhost> Message-ID: <053.bebb44a50f85efbd777266af09eb9677@localhost> #2250: unpackFamily on Windows 2008 fails match -------------------------------+-------------------------------------------- Reporter: larsv | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -------------------------------+-------------------------------------------- Comment (by igloo): Great stuff, thanks! It looks like it should be `CSaFamily` rather than `CInt`. Likewise `packFamily`, and I expect the whole library could do with an audit. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 7 14:13:42 2008 From: trac at galois.com (GHC) Date: Wed May 7 14:08:35 2008 Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost> References: <050.c31695132cb1b93380c95a8b6c208782@localhost> Message-ID: <059.bc1aa29e4e9926d671220a2a554df7bf@localhost> #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: high | Milestone: Not GHC Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Comment (by eelco): I believe XCode 3.1 is released as part of the iPhone SDK (http://developer.apple.com/iphone/). I'm not sure if it's going to be released 'stand-alone' as well. I'm now installing it, to test if the bug is fixed for that version. I'll report back in a couple of hours ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 7 16:47:16 2008 From: trac at galois.com (GHC) Date: Wed May 7 16:41:21 2008 Subject: [GHC] #1434: Slow conversion from Double to Int In-Reply-To: <064.721fd4548a9d950dbdd8525731a58ee4@localhost> References: <064.721fd4548a9d950dbdd8525731a58ee4@localhost> Message-ID: <073.e622475093e6a34cf12798beeb14e0ba@localhost> #1434: Slow conversion from Double to Int ---------------------------------------+------------------------------------ Reporter: ghc@henning-thielemann.de | Owner: dons Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ---------------------------------------+------------------------------------ Changes (by dons): * owner: => dons * cc: dons@galois.com (added) Comment: I looked into this after the realToFrac issues last week. It's a similar story -- the noop rules are currently only set up for Int conversions. So, for example, this program: {{{ import Data.Word import Data.Array.Vector main = print . sumU . mapU (truncate::Double->Word16) $ (enumFromToFracU 0.1 (100000000 :: Double)) }}} truncate stays as a call to properFraction. Now, we can add some rules for this stuff: {{{ {-# RULES "truncate/Double->Int64" truncate = fromIntegral . double2Int :: Double -> Int64 "truncate/Double->Int32" truncate = fromIntegral . double2Int :: Double -> Int32 "truncate/Double->Int16" truncate = fromIntegral . double2Int :: Double -> Int16 "truncate/Double->Int8" truncate = fromIntegral . double2Int :: Double -> Int8 "truncate/Double->Word64" truncate = fromIntegral . double2Int :: Double -> Word64 "truncate/Double->Word32" truncate = fromIntegral . double2Int :: Double -> Word32 "truncate/Double->Word16" truncate = fromIntegral . double2Int :: Double -> Word16 "truncate/Double->Word8" truncate = fromIntegral . double2Int :: Double -> Word8 #-} }}} And the running time drops from: {{{ $ time ./henning 28800 ./henning 45.84s user 0.11s system 98% cpu 46.448 total }}} before, to: {{{ $ time ./henning 28800 ./henning 0.39s user 0.00s system 97% cpu 0.398 total }}} after. I think this is as good a time as any to do an audit of the Int/noop conversion rules in base, looking for others that also should work for integral types. I'll take care of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 7 17:45:13 2008 From: trac at galois.com (GHC) Date: Wed May 7 17:39:25 2008 Subject: [GHC] #1434: Slow conversion from Double to Int In-Reply-To: <064.721fd4548a9d950dbdd8525731a58ee4@localhost> References: <064.721fd4548a9d950dbdd8525731a58ee4@localhost> Message-ID: <073.acb8af5bb711cb1643bf66373f7d4ea3@localhost> #1434: Slow conversion from Double to Int ---------------------------------------+------------------------------------ Reporter: ghc@henning-thielemann.de | Owner: dons Type: task | Status: new Priority: normal | Milestone: 6.8 branch Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: rules | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ---------------------------------------+------------------------------------ Changes (by dons): * keywords: => rules * type: bug => task Comment: While hunting around, I noticed we have nice RULES defined for the basic math and boolean ops, {{{ "x# ># x#" forall x#. x# ># x# = False "x# >=# x#" forall x#. x# >=# x# = True "x# ==# x#" forall x#. x# ==# x# = True "x# /=# x#" forall x#. x# /=# x# = False "x# <# x#" forall x#. x# <# x# = False "x# <=# x#" forall x#. x# <=# x# = True }}} For example, but I couldn't see rules for the Word# primitives. However, if I write test cases, {{{ x = case int2Word# 7# of x# -> x# `gtWord#` x# }}} We do get rules firing, {{{ 2 RuleFired 1 gtWord# 1 int2Word# M.x = False }}} Where are the Word# rules defined? Are they wired in? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 7 19:17:37 2008 From: trac at galois.com (GHC) Date: Wed May 7 19:11:47 2008 Subject: [GHC] #2269: Word type to Double or Float conversions are slower than Int conversions Message-ID: <043.be417919ffcce10010ccb473704f0755@localhost> #2269: Word type to Double or Float conversions are slower than Int conversions -------------------------------------------+-------------------------------- Reporter: dons | Owner: dons@galois.com Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: rules, performance, double | Testcase: Architecture: Unknown | Os: Unknown -------------------------------------------+-------------------------------- We have int2Double# and int2Float# primitives, but not equivalent ones for Word types. We may need word2Double# too, for Words* to be fully first-class performance-wise. This means we have to do extra tests in the Num instances for Word types to implement 'fromIntegral': {{{ toInteger (W# x#) | i# >=# 0# = smallInteger i# | otherwise = wordToInteger x# where i# = word2Int# x# }}} Now, for some types, we work around this: {{{ "fromIntegral/Int->Word" fromIntegral = \(I# x#) -> W# (int2Word# x#) "fromIntegral/Word->Int" fromIntegral = \(W# x#) -> I# (word2Int# x#) "fromIntegral/Word->Word" fromIntegral = id :: Word -> Word }}} and so on for other Word/Int types. And all is fine. The problem comes up for Float and Double. For Int, we can write: {{{ "fromIntegral/Int->Float" fromIntegral = int2Float "fromIntegral/Int->Double" fromIntegral = int2Double int2Float :: Int -> Float int2Float (I# x) = F# (int2Float# x) int2Double :: Int -> Double int2Double (I# x) = D# (int2Double# x) }}} But we can't write these rules for Word types. The result is a slow down on Word conversions, consider this program: {{{ main = print . sumU . mapU (fromIntegral::Int->Double) $ enumFromToU 0 100000000 }}} When in lhs is Int, we get this nice code: {{{ $wfold :: Double# -> Int# -> Double# $wfold = \ (ww_s18k :: Double#) (ww1_s18o :: Int#) -> case ># ww1_s18o 100000000 of wild_a14T { False -> $wfold (+## ww_s18k (int2Double# ww1_s18o)) (+# ww1_s18o 1); True -> ww_s18k }}} But for Word types, we get: {{{ $wfold :: Double# -> Word# -> Double# $wfold = \ (ww_s1gN :: Double#) (ww1_s1gR :: Word#) -> case gtWord# ww1_s1gR __word 100000000 of wild_a1do { False -> case case >=# (word2Int# ww1_s1gR) 0 of wild1_a1cS { False -> case word2Integer# ww1_s1gR of wild11_a1d9 { (# s_a1db, d_a1dc #) -> case {__ccall __encodeDouble Int# -> ByteArray# -> Int# -> State# RealWorld -> (# State# RealWorld, Double# #)}_a1bT s_a1db d_a1dc 0 realWorld# of wild12_a1bX { (# ds1_a1bZ, ds2_a1c0 #) -> ds2_a1c0 } }; True -> int2Double# (word2Int# ww1_s1gR) } of wild1_a1bM { __DEFAULT -> $wfold (+## ww_s1gN wild1_a1bM) (plusWord# ww1_s1gR __word 1) }; True -> ww_s1gN } }}} Which is to be expected, and the running time goes from: {{{ $ time ./henning 5.00000000067109e17 ./henning 1.53s user 0.00s system 99% cpu 1.534 total }}} To: {{{ $ time ./henning 5.00000000067109e17 ./henning 4.57s user 0.00s system 99% cpu 4.571 total }}} So not too bad, but still, principle of least surprise says Word and Int should behave the same. Should we have a word2Double# primop? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 7 19:52:35 2008 From: trac at galois.com (GHC) Date: Wed May 7 19:46:43 2008 Subject: [GHC] #2270: gcd is specialised only for Int Message-ID: <043.b1b4c47bccdeb536ea28564b64a56127@localhost> #2270: gcd is specialised only for Int ------------------------+--------------------------------------------------- Reporter: dons | Owner: dons@galois.com Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- We have the general: {{{ gcd :: (Integral a) => a -> a -> a gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined" gcd x y = gcd' (abs x) (abs y) where gcd' a 0 = a gcd' a b = gcd' b (a `rem` b) }}} And a specialisation for Int only: {{{ {-# RULES "gcd/Int->Int->Int" gcd = gcdInt #-} gcdInt (I# a) (I# b) = g a b where g 0# 0# = error "GHC.Base.gcdInt: gcd 0 0 is undefined" g 0# _ = I# absB g _ 0# = I# absA g _ _ = I# (gcdInt# absA absB }}} Thanks to the gcdInt# primop. If we use Word here, or other Int types, we get the slow version (which is only 10x slower, surprisingly): {{{ main = print . sumU . mapU (gcd 2) $ enumFromToU 0 (100000000 :: Word) }}} Comes out as: {{{ time ./henning 150000002 ./henning 25.73s user 0.05s system 99% cpu 25.936 total }}} Versus: {{{ $ time ./henning 150000002 ./henning 2.33s user 0.00s system 99% cpu 2.334 tota }}} So there are two things we can do here to improve the situation: == Step 1: Add rules for getting from the other Int* types to gcdInt# == {{{ {-# RULES "gcd/Int32->Int32->Int32" gcd = gcdInt32 #-} gcdInt32 :: Int32 -> Int32 -> Int32 gcdInt32 x y = fromIntegral ((gcd :: Int -> Int -> Int) (fromIntegral x) (fromIntegral y)) }}} For example, takes the running time from 28 seconds to 2.4seconds, for: {{{ main = print . sumU . mapU (gcd 2) $ enumFromToU 0 (100000000 :: Int32) }}} == Step 2: optionally add a gcdWord# == We could then also add a gcdWord# primop,or perhaps just following fromIntegral, and test for negative first, then conditionally dispatch to gcdInt. What do people think? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 7 20:28:53 2008 From: trac at galois.com (GHC) Date: Wed May 7 20:23:06 2008 Subject: [GHC] #2271: floor, ceiling, round :: Double -> Int are awesomely slow Message-ID: <043.845265305898c52232b3689d70d3b99c@localhost> #2271: floor, ceiling, round :: Double -> Int are awesomely slow ------------------------------------------+--------------------------------- Reporter: dons | Owner: dons@galois.com Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: performance, math, double | Testcase: Architecture: Unknown | Os: Unknown ------------------------------------------+--------------------------------- We have super-naive implementations of the RealFrac class for Double. Consider: {{{ {-# RULES "truncate/Double->Int" truncate = double2Int #-} instance RealFrac Double where properFraction x = case (decodeFloat x) of { (m,n) -> let b = floatRadix x in if n >= 0 then (fromInteger m * fromInteger b ^ n, 0.0) else case (quotRem m (b^(negate n))) of { (w,r) -> (fromInteger w, encodeFloat r n) } } floor x = case properFraction x of (n,r) -> if r < 0.0 then n - 1 else n }}} So now, we *do* have a good rule for truncate, but floor, ceiling and round turn out to be awesomely slow. {{{ main = print . sumU . mapU (floor :: Double -> Int) $ enumFromToFracU 0 100000000 }}} Runs in 1 minute, 10 seconds: {{{ $ time ./henning 5000000050000000 ./henning 70.25s user 0.17s system 99% cpu 1:10.99 total }}} Now, if we just replace that with a ccall to math.h:floor, we get: {{{ main = print . sumU . mapU (floor' :: Double -> Int) $ enumFromToFracU 0 100000000 floor' :: Double -> Int floor' x = (truncate :: Double -> Int) (c_floor x) {-# INLINE floor' #-} foreign import ccall unsafe "math.h floor" c_floor :: Double -> Double }}} Which runs in 1.8 seconds: {{{ $ time ./henning 5000000050000000 ./henning 1.88s user 0.00s system 99% cpu 1.884 total }}} Similar results for ceiling and round (see the main ticket for RealFrac, http://hackage.haskell.org/trac/ghc/ticket/1434) == Action == Use math.h versions of round, floor and ceiling for Double and Float? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 8 02:22:59 2008 From: trac at galois.com (GHC) Date: Thu May 8 02:17:20 2008 Subject: [GHC] #1968: data family + GADT: not implemented yet In-Reply-To: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> References: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> Message-ID: <052.6624123da9716dea66b747b6ebdf6488@localhost> #1968: data family + GADT: not implemented yet ------------------------------------------------+--------------------------- Reporter: Remi | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: data type family GADT choose_univs | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ------------------------------------------------+--------------------------- Comment (by chak): Replying to [comment:3 guest]: > Also interested in this. Will the implementation allow varying non- instance types? What do you mean by "varying non-instance type"? Whether you write {{{ data family Blah x y :: * }}} or {{{ data family Blah x :: * -> * }}} makes no difference whatsoever for data families. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 8 03:34:36 2008 From: trac at galois.com (GHC) Date: Thu May 8 03:28:38 2008 Subject: [GHC] #2228: runghc screws up terminal buffering mode and doesn't reset it In-Reply-To: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> References: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> Message-ID: <053.45feb1223ad4451dd6469d6dd746058a@localhost> #2228: runghc screws up terminal buffering mode and doesn't reset it --------------------+------------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------+------------------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: To merge: {{{ Tue Apr 29 23:24:09 BST 2008 Simon Marlow * don't turn off stdin/stdout buffering after loading a module with ghc -e (#2228) Tue Apr 29 23:24:42 BST 2008 Simon Marlow * change topHandlerFastExit to topHandler, so the terminal state gets restored (#2228) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 8 06:19:34 2008 From: trac at galois.com (GHC) Date: Thu May 8 06:13:41 2008 Subject: [GHC] #1968: data family + GADT: not implemented yet In-Reply-To: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> References: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> Message-ID: <052.83d93e5ca1c79a5ebbdfbe313a22bfaf@localhost> #1968: data family + GADT: not implemented yet ------------------------------------------------+--------------------------- Reporter: Remi | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: data type family GADT choose_univs | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ------------------------------------------------+--------------------------- Comment (by guest): Ah, ok. By varying non-instance types, I meant are the constructors allowed to refine the types that don't index the family. However I've just realised/remembered there isn't a distinction between the named and kind- annotated types - my mistake. I guess I was thinking that named variables somehow index the data family, (as with type families) and so you could determine which instance to use, and whether one is uniquely determined by a signature. Just to totally clarify - of the 3 programs below, the first is a type error and the other two are type ok and equivalent? {{{ {-# LANGUAGE GADTs, TypeFamilies, KindSignatures #-} data family Blah x a :: * data instance Blah Char Int where Char1 :: Blah Char Int data instance Blah Char Bool where Char2 :: Blah Char Bool foo :: Blah Char a -> a foo Char1 = 2 foo Char2 = False }}} vs {{{ {-# LANGUAGE GADTs, TypeFamilies, KindSignatures #-} data family Blah x :: * -> * data instance Blah Char a where Char1 :: Blah Char Int Char2 :: Blah Char Bool foo :: Blah Char a -> a foo Char1 = 2 foo Char2 = False }}} vs {{{ {-# LANGUAGE GADTs, TypeFamilies, KindSignatures #-} data family Blah x a :: * data instance Blah Char a where Char1 :: Blah Char Int Char2 :: Blah Char Bool foo :: Blah Char a -> a foo Char1 = 2 foo Char2 = False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 8 06:40:06 2008 From: trac at galois.com (GHC) Date: Thu May 8 06:34:20 2008 Subject: [GHC] #1861: Uncompilable code generated In-Reply-To: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> References: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> Message-ID: <053.4047b677ada7d2bb4a0d021fdc987947@localhost> #1861: Uncompilable code generated ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by simonmar): you can use the C constant `INFINITY`, which is defined by `math.h` (which we `#include` in generated C). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 8 10:04:51 2008 From: trac at galois.com (GHC) Date: Thu May 8 09:58:52 2008 Subject: [GHC] #2272: internal error: getMBlock: mmap: Bad file number Message-ID: <044.485296ba49fdd540ac589cc1c46011fb@localhost> #2272: internal error: getMBlock: mmap: Bad file number ------------------------+--------------------------------------------------- Reporter: hpwei | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Solaris ------------------------+--------------------------------------------------- I cut and paste the code from http://blog.moertel.com/articles/2004/03/13/concurrent-port-scanner-in- haskell And compiled the resulting portscan.hs with both ghc-6.8.2 and ghc-6.6.1 on a host with Sun-Sparc [SunOS 5.10]. The following error occurred when the code was invoked. portscan a_remote_sun_sparc_machine 1 1000 portscan: internal error: getMBlock: mmap: Bad file number (GHC version 6.6.1 for sparc_sun_solaris2) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort [ note: same result for 6.8.2 ] [ note: if the remote machine is a linux machine, then the code works. ] --HP -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 8 10:47:22 2008 From: trac at galois.com (GHC) Date: Thu May 8 10:41:29 2008 Subject: [GHC] #1968: data family + GADT: not implemented yet In-Reply-To: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> References: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> Message-ID: <052.579462677aa74e4802c050ebbb537f92@localhost> #1968: data family + GADT: not implemented yet ------------------------------------------------+--------------------------- Reporter: Remi | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: data type family GADT choose_univs | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ------------------------------------------------+--------------------------- Comment (by simonpj): Correct, I think. You definitely can't mix data contructors from two different 'data instances'. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 8 11:30:30 2008 From: trac at galois.com (GHC) Date: Thu May 8 11:24:41 2008 Subject: [GHC] #1861: Uncompilable code generated In-Reply-To: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> References: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> Message-ID: <053.867f34ce78ed2c048529f827130224f9@localhost> #1861: Uncompilable code generated ----------------------+----------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => simonmar Comment: The problem is located at line 398 of `codeGen/PprC.hs`, which prints float/double constants in a form the C compiler understands. Two alternatives * Do what native code gen does: generate a hex constant and cast. Perhaps non-portable. * Do conditional tests to check for infinite values and `INFINITY`. Also minus-infinite and NaN need checked. In effect, this means moving the `fromRational` call in `Outputable.rational` into `PprC`. Simon M recommends the second for now. And will do! Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 8 13:05:39 2008 From: trac at galois.com (GHC) Date: Thu May 8 12:59:43 2008 Subject: [GHC] #2273: inlining defeats seq Message-ID: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> #2273: inlining defeats seq -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Consider this module: {{{ module Q (tcExtendIdEnv2) where -- Interesting code: tcExtendIdEnv2 :: M a tcExtendIdEnv2 = do env <- getEnv let level :: Int level = thLevel (tcl_th_ctxt env) level `seq` tc_extend_local_id_env level {-# NOINLINE tc_extend_local_id_env #-} tc_extend_local_id_env :: Int -> M a tc_extend_local_id_env th_lvl = if read "foo" then th_lvl `seq` return undefined else return undefined thLevel :: ThStage -> Int thLevel Comp = 0 thLevel (Splice l) = l thLevel (Brack l) = l -- Dull code: type M a = IOEnv TcLclEnv a data TcLclEnv = TcLclEnv { tcl_th_ctxt :: !ThStage } data ThStage = Comp | Splice Int | Brack Int getEnv :: IOEnv env env getEnv = IOEnv (\ env -> return env) newtype IOEnv env a = IOEnv { unIOEnv :: env -> IO a } instance Monad (IOEnv m) where IOEnv m >>= f = IOEnv (\ env -> do r <- m env unIOEnv (f r) env ) return a = IOEnv (\ _ -> return a) fail = error }}} Compiling with {{{ ghc -O -ddump-simpl -ddump-stg -c Q.hs }}} we get, in the STG, {{{ Q.$wa = \r srt:(0,*bitmap*) [ww_sDx w_sDO] case case ww_sDx of wild_sEs { Q.Comp -> Q.lvl; Q.Splice l_sDA -> l_sDA; Q.Brack l_sDC -> l_sDC; } of tpl_sEt { GHC.Base.I# ipv_sEu -> let { sat_sDN = NO_CCS Q.TcLclEnv! [ww_sDx]; } in let { sat_sDL = \u [] case ww_sDx of wild_sEv { Q.Comp -> Q.lvl; Q.Splice l_sDH -> l_sDH; Q.Brack l_sDJ -> l_sDJ; }; } in Q.tc_extend_local_id_env sat_sDL sat_sDN w_sDO; }; }}} GHC seems to have inlined `level`, forced it (due to the seq), but passed along a second, inlined, unevaluated copy to `tc_extend_local_id_env`. So the whole environment is retained, defeating the purpose of the seq! If I mark `level` as `NOINLINE` then the STG looks like this: {{{ Q.a5 = \r srt:(0,*bitmap*) [env_sD1 eta_sDh] case env_sD1 of tpl_sDg { Q.TcLclEnv ipv_sD5 -> case case ipv_sD5 of wild_sDN { Q.Comp -> Q.lvl; Q.Splice l_sD8 -> l_sD8; Q.Brack l_sDa -> l_sDa; } of level_sDc { __DEFAULT -> case level_sDc of tpl1_sDf { GHC.Base.I# ipv1_sDO -> Q.tc_extend_local_id_env tpl1_sDf tpl_sDg eta_sDh; }; }; }; }}} which fixes the env-retained problem, although I don't understand why two cases are done. It would be nice not to have to resort to this level of trickery, though! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 8 16:01:25 2008 From: trac at galois.com (GHC) Date: Thu May 8 15:55:26 2008 Subject: [GHC] #2274: ghc assumes sizeof (void *) != 32 on X86_64 Message-ID: <042.aa91907ac8eab8de52d65ac1d0bbc793@localhost> #2274: ghc assumes sizeof (void *) != 32 on X86_64 --------------------------------+------------------------------------------- Reporter: ion | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: blocker Keywords: 64 configure 32 | Testcase: Architecture: x86_64 (amd64) | Os: Linux --------------------------------+------------------------------------------- My provider has a 32-bit debian installed on a 64-bit architecture, ghc 8.2 cannot be compiled there (from 'uname -m' the bootstrapping assumes a 64 bit target architecture, while later a configure test will find 'sizof (void *)' is 4: this leads to compilation errors with CPP conditional compilation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 8 17:22:43 2008 From: trac at galois.com (GHC) Date: Thu May 8 17:16:44 2008 Subject: [GHC] #1380: Safe Haskell In-Reply-To: <044.3b0885c88c35a1aacdb90750c7783a3a@localhost> References: <044.3b0885c88c35a1aacdb90750c7783a3a@localhost> Message-ID: <053.ef3698d2c8446cde5f98bdf13eb737d3@localhost> #1380: Safe Haskell -----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: None | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by ion): Modula 3 has a system of safe/unsafe modules. By default, all modules are considered safe (here `safe` means that the runtime environment may not crash). If unsafe things like pointers are to be used, the module must be explicitly marked as `unsafe`. Safe modules can only import safe modules.[[BR]] The syntax could be (similar to Modula 3): [[BR]] {{{ module Prelude where ... unsafe module X where ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 8 21:00:40 2008 From: trac at galois.com (GHC) Date: Thu May 8 20:54:45 2008 Subject: [GHC] #1968: data family + GADT: not implemented yet In-Reply-To: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> References: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> Message-ID: <052.38bc0a2a169ea33ce3881967f22b807f@localhost> #1968: data family + GADT: not implemented yet ------------------------------------------------+--------------------------- Reporter: Remi | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: data type family GADT choose_univs | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ------------------------------------------------+--------------------------- Comment (by chak): Yes, as Simon says, you are perfectly right about the three examples. Just as a final remark on that topic, the reason why it is tempting to think that "naming" a parameter in a `data family` declaration makes a difference is because it '''does''' make a difference for a `type family`. This is a point where data families and type synonym families are fundamentally different. The underlying type theoretic rational derives from the fact that a data family always introduces a '''new''' type, whereas a synonym family doesn't. A secondary consequence is that data families may be applied partially, whereas a synonym family must always be applied to at least as many type arguments as its arity (i.e., the number of named parameters in the declaration). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 9 04:41:41 2008 From: trac at galois.com (GHC) Date: Fri May 9 04:35:41 2008 Subject: [GHC] #2275: Poor indication of type error location Message-ID: <044.43d81bf78db38afe22fab3304ba5b342@localhost> #2275: Poor indication of type error location ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Using {-# OPTIONS_GHC -XArrows -fno-monomorphism-restriction #-}, and Yampa Starting from line 32, my program contains: fireworkSF :: Point2 GL.GLdouble -> Point2 GL.GLdouble -> Object fireworkSF p0 pFinal = proc _ -> do rec position <- (p0 .+^) ^<< integral -< v0 let shouldExplode = position == pFinal let killReq = if shouldExplode then Event () else noEvent let spawnReq = if shouldExplode then Event (Explode pFinal) else noEvent returnA -< ObjectOutput {oState = FireworkState position ,oKillReq = killReq ,oSpawnReq = spawnReq} where v0 = (pFinal ^-^ p0) ^/ 2 The type error reports: Firework.hs:32:0: Couldn't match expected type `Point2 GL.GLdouble' against inferred type `Vector2 GL.GLdouble' When using functional dependencies to combine AffineSpace (Point2 a) (Vector2 a) a, arising from the instance declaration at AffineSpace (Point2 GL.GLdouble) (Point2 GL.GLdouble) a, arising from a use of `.+^' at Firework.hs:34:16-23 When generalising the type(s) for `fireworkSF' Indicating that the bug is something to do with line 34. The actual bug is that the last line of the paste should read: v0 = (pFinal .-. p0) ^/ 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 9 04:43:36 2008 From: trac at galois.com (GHC) Date: Fri May 9 04:37:35 2008 Subject: [GHC] #2275: Poor indication of type error location In-Reply-To: <044.43d81bf78db38afe22fab3304ba5b342@localhost> References: <044.43d81bf78db38afe22fab3304ba5b342@localhost> Message-ID: <053.34f531077d61c67f22b4511bbfe50446@localhost> #2275: Poor indication of type error location ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- Comment (by guest): Sorry, here's the code again: {{{ fireworkSF :: Point2 GL.GLdouble -> Point2 GL.GLdouble -> Object fireworkSF p0 pFinal = proc _ -> do rec position <- (p0 .+^) ^<< integral -< v0 let shouldExplode = position == pFinal let killReq = if shouldExplode then Event () else noEvent let spawnReq = if shouldExplode then Event (Explode pFinal) else noEvent returnA -< ObjectOutput {oState = FireworkState position ,oKillReq = killReq ,oSpawnReq = spawnReq} where v0 = (pFinal ^-^ p0) ^/ 2 }}} And the error: {{{ Firework.hs:32:0: Couldn't match expected type `Point2 GL.GLdouble' against inferred type `Vector2 GL.GLdouble' When using functional dependencies to combine AffineSpace (Point2 a) (Vector2 a) a, arising from the instance declaration at AffineSpace (Point2 GL.GLdouble) (Point2 GL.GLdouble) a, arising from a use of `.+^' at Firework.hs:34:16-23 When generalising the type(s) for `fireworkSF' }}} and the correct line: {{{ v0 = (pFinal .-. p0) ^/ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 9 08:04:19 2008 From: trac at galois.com (GHC) Date: Fri May 9 07:58:17 2008 Subject: [GHC] #2275: Poor indication of type error location In-Reply-To: <044.43d81bf78db38afe22fab3304ba5b342@localhost> References: <044.43d81bf78db38afe22fab3304ba5b342@localhost> Message-ID: <053.fc92b728d5e2787f22bc674eaecf158e@localhost> #2275: Poor indication of type error location -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > Using {-# OPTIONS_GHC -XArrows -fno-monomorphism-restriction #-}, and > Yampa > Starting from line 32, my program contains: > > fireworkSF :: Point2 GL.GLdouble -> Point2 GL.GLdouble -> Object > fireworkSF p0 pFinal = proc _ -> do > rec > position <- (p0 .+^) ^<< integral -< v0 > let shouldExplode = position == pFinal > let killReq = if shouldExplode then Event () else noEvent > let spawnReq = if shouldExplode > then Event (Explode pFinal) > else noEvent > returnA -< ObjectOutput {oState = FireworkState position > ,oKillReq = killReq > ,oSpawnReq = spawnReq} > where > v0 = (pFinal ^-^ p0) ^/ 2 > > The type error reports: > Firework.hs:32:0: > Couldn't match expected type `Point2 GL.GLdouble' > against inferred type `Vector2 GL.GLdouble' > When using functional dependencies to combine > AffineSpace (Point2 a) (Vector2 a) a, > arising from the instance declaration at > AffineSpace (Point2 GL.GLdouble) (Point2 GL.GLdouble) a, > arising from a use of `.+^' at Firework.hs:34:16-23 > When generalising the type(s) for `fireworkSF' > > Indicating that the bug is something to do with line 34. The actual bug > is that the last line of the paste should read: > v0 = (pFinal .-. p0) ^/ 2 New description: Using {-# OPTIONS_GHC -XArrows -fno-monomorphism-restriction #-}, and Yampa Starting from line 32, my program contains: {{{ fireworkSF :: Point2 GL.GLdouble -> Point2 GL.GLdouble -> Object fireworkSF p0 pFinal = proc _ -> do rec position <- (p0 .+^) ^<< integral -< v0 let shouldExplode = position == pFinal let killReq = if shouldExplode then Event () else noEvent let spawnReq = if shouldExplode then Event (Explode pFinal) else noEvent returnA -< ObjectOutput {oState = FireworkState position ,oKillReq = killReq ,oSpawnReq = spawnReq} where v0 = (pFinal ^-^ p0) ^/ 2 }}} The type error reports: {{{ Firework.hs:32:0: Couldn't match expected type `Point2 GL.GLdouble' against inferred type `Vector2 GL.GLdouble' When using functional dependencies to combine AffineSpace (Point2 a) (Vector2 a) a, arising from the instance declaration at AffineSpace (Point2 GL.GLdouble) (Point2 GL.GLdouble) a, arising from a use of `.+^' at Firework.hs:34:16-23 When generalising the type(s) for `fireworkSF' }}} Indicating that the bug is something to do with line 34. The actual bug is that the last line of the paste should read: {{{ v0 = (pFinal .-. p0) ^/ 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 9 08:31:07 2008 From: trac at galois.com (GHC) Date: Fri May 9 08:25:07 2008 Subject: [GHC] #2269: Word type to Double or Float conversions are slower than Int conversions In-Reply-To: <043.be417919ffcce10010ccb473704f0755@localhost> References: <043.be417919ffcce10010ccb473704f0755@localhost> Message-ID: <052.b3e84d096433dc5f7ba60ea72dcec7ac@localhost> #2269: Word type to Double or Float conversions are slower than Int conversions ----------------------------------------+----------------------------------- Reporter: dons | Owner: dons@galois.com Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: rules, performance, double | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------------+----------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: I'd like `word2Double#` and `word2Float#` for integer-simple too, so it sounds good to me! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 9 09:52:03 2008 From: trac at galois.com (GHC) Date: Fri May 9 09:46:33 2008 Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost> References: <050.c31695132cb1b93380c95a8b6c208782@localhost> Message-ID: <059.b6d83f364e5e7357c52206bbf5a4a7fb@localhost> #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: high | Milestone: Not GHC Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Comment (by eelco): It took me a bit longer than expected, but I can confirm that ghc 6.8.2 built succesfully using XCode 3.1 (from the iPhone SDK package). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 9 11:51:59 2008 From: trac at galois.com (GHC) Date: Fri May 9 11:45:59 2008 Subject: [GHC] #2276: foreign import stdcall "&foo" doesn't work Message-ID: <047.799717800ba2c37716201ce0aa31af44@localhost> #2276: foreign import stdcall "&foo" doesn't work -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Importing a label with the stdcall calling convention fails to remember the stdcall attribute and add the appropriate '@n' suffix to the label on Windows. e.g. {{{ foreign import stdcall "&foo" foo :: FunPtr (CInt -> IO ()) }}} should result in a reference to "foo@4", but doesn't. This breaks the Win32 library, which does something like this for `genericWndProc` in `Graphics/Win32/Window.hsc`. Somewhat related to to #1288 . -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 9 21:55:36 2008 From: trac at galois.com (GHC) Date: Fri May 9 21:49:37 2008 Subject: [GHC] #2277: GHCi silently aborts on 'take' computation Message-ID: <046.02df5e44a831fb20777998dee9adae29@localhost> #2277: GHCi silently aborts on 'take' computation -------------------------------+-------------------------------------------- Reporter: cdsmith | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- With latest GHC from darcs repository, on an AMD64 system, performing a 'take' computation with an infinite or very long list causes GHCi to exit without warning. This happens regardless of whether the list is the result of {{{let x = 2:x}}} or {{{let x = [2,2..]}}} or {{{let x = replicate 10000 2}}}. There is no problem in GHC 6.8.2. {{{ cdsmith@godel:~$ ghci -v GHCi, version 6.9.20080507: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 6.9.20080507, for Haskell 98, stage 2 booted by GHC version 6.8.2 Using package config file: /usr/local/lib/ghc-6.9.20080507/package.conf hiding package bytestring-0.9 to avoid conflict with later version bytestring-0.9.1.0 wired-in package ghc-prim mapped to ghc-prim-0.1 wired-in package integer mapped to integer-0.1 wired-in package base mapped to base-3.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1 wired-in package template-haskell mapped to template-haskell-2.2 wired-in package ndp not found. Hsc static flags: -static *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: hiding package bytestring-0.9 to avoid conflict with later version bytestring-0.9.1.0 wired-in package ghc-prim mapped to ghc-prim-0.1 wired-in package integer mapped to integer-0.1 wired-in package base mapped to base-3.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1 wired-in package template-haskell mapped to template-haskell-2.2 wired-in package ndp not found. hiding package bytestring-0.9 to avoid conflict with later version bytestring-0.9.1.0 wired-in package ghc-prim mapped to ghc-prim-0.1 wired-in package integer mapped to integer-0.1 wired-in package base mapped to base-3.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1 wired-in package template-haskell mapped to template-haskell-2.2 wired-in package ndp not found. hiding package bytestring-0.9 to avoid conflict with later version bytestring-0.9.1.0 wired-in package ghc-prim mapped to ghc-prim-0.1 wired-in package integer mapped to integer-0.1 wired-in package base mapped to base-3.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1 wired-in package template-haskell mapped to template-haskell-2.2 wired-in package ndp not found. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: Prelude> let x = 2:x *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: Prelude> take 1000 x *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: [2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ] Leaving GHCi. *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: }}} But with a GHC 6.8.2, everything works fine: {{{ cdsmith@godel:~$ /usr/bin/ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> let x = 2:x Prelude> take 1000 x [2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ] Prelude> :q Leaving GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 10 06:23:35 2008 From: trac at galois.com (GHC) Date: Sat May 10 06:17:31 2008 Subject: [GHC] #2277: GHCi silently aborts on 'take' computation In-Reply-To: <046.02df5e44a831fb20777998dee9adae29@localhost> References: <046.02df5e44a831fb20777998dee9adae29@localhost> Message-ID: <055.9b3081fe0210edf6176bc293f5d064da@localhost> #2277: GHCi silently aborts on 'take' computation ---------------------+------------------------------------------------------ Reporter: cdsmith | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the report. It works in my amd64/Linux 6.9.20080506 validate build, though. Can you describe how you are building GHC please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 10 22:49:27 2008 From: trac at galois.com (GHC) Date: Sat May 10 22:43:24 2008 Subject: [GHC] #2277: GHCi silently aborts on 'take' computation In-Reply-To: <046.02df5e44a831fb20777998dee9adae29@localhost> References: <046.02df5e44a831fb20777998dee9adae29@localhost> Message-ID: <055.3be886ace85cfe5e9119be0686ded6aa@localhost> #2277: GHCi silently aborts on 'take' computation ---------------------+------------------------------------------------------ Reporter: cdsmith | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Comment (by cdsmith): That's odd. I'm not doing anything unusual. Just {{{ darcs get http://darcs.haskell.org/ghc cd ghc ./darcs-all get sh boot make make install }}} I don't see anything unusual during the build. I guess one thing I did recently was install the editline library, and I noticed that GHC didn't build the readline package, so I assume it's using editline instead. I'll try undoing that change, and update the ticket with results. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 10 22:50:58 2008 From: trac at galois.com (GHC) Date: Sat May 10 22:44:51 2008 Subject: [GHC] #2277: GHCi silently aborts on 'take' computation In-Reply-To: <046.02df5e44a831fb20777998dee9adae29@localhost> References: <046.02df5e44a831fb20777998dee9adae29@localhost> Message-ID: <055.ee746e0fa7b054d3e0954991a61ceb72@localhost> #2277: GHCi silently aborts on 'take' computation ---------------------+------------------------------------------------------ Reporter: cdsmith | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Comment (by cdsmith): Oops, obviously, I left out a line in copying the commands from the command window. I also did: {{{ ./configure --with-ghc=/usr/bin/ghc }}} where /usr/bin/ghc is GHC 6.8.2 as packaged by Ubuntu. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 11 07:55:26 2008 From: trac at galois.com (GHC) Date: Sun May 11 07:49:18 2008 Subject: [GHC] #2278: Inconsistent behaviour between -odir and -hidir options Message-ID: <044.da2157b8bb277561bb6fe2b75576c141@localhost> #2278: Inconsistent behaviour between -odir and -hidir options -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------+---------------------------------------------------- (From Adrian Hey) The -hidir option creates if it does not already exist, but -odir gives an error instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 11 18:12:23 2008 From: trac at galois.com (GHC) Date: Sun May 11 18:06:18 2008 Subject: [GHC] #2072: freebsd/amd64: don't know how to mangle assembly language In-Reply-To: <046.3e104ec5c02d771b814fafeb449f23f1@localhost> References: <046.3e104ec5c02d771b814fafeb449f23f1@localhost> Message-ID: <055.ec2f85f7235cce0f8da7c90fca0dbf25@localhost> #2072: freebsd/amd64: don't know how to mangle assembly language ----------------------+----------------------------------------------------- Reporter: newsham | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: ghc-asm | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo * type: bug => merge Comment: Merge: {{{ Sun May 11 11:20:11 PDT 2008 Ian Lynagh * Tell the mangler how to mangle for amd64/freebsd; fixes trac #2072 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 12 04:46:17 2008 From: trac at galois.com (GHC) Date: Mon May 12 04:40:08 2008 Subject: [GHC] #2274: ghc assumes sizeof (void *) != 32 on X86_64 In-Reply-To: <042.aa91907ac8eab8de52d65ac1d0bbc793@localhost> References: <042.aa91907ac8eab8de52d65ac1d0bbc793@localhost> Message-ID: <051.dceed3f8a2a85437d32902f478a87c7d@localhost> #2274: ghc assumes sizeof (void *) != 32 on X86_64 -----------------------------+---------------------------------------------- Reporter: ion | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: blocker | Resolution: duplicate Keywords: 64 configure 32 | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: this is the same issue as #1717 The workaround is to use `linux32 ./configure`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 12 05:18:22 2008 From: trac at galois.com (GHC) Date: Mon May 12 05:12:12 2008 Subject: [GHC] #2234: Profiled binaries create empty files In-Reply-To: <044.7102554d75e5a8588c921a04c46a11b1@localhost> References: <044.7102554d75e5a8588c921a04c46a11b1@localhost> Message-ID: <053.376f9a8224bf5b6167e38a5a0630388e@localhost> #2234: Profiled binaries create empty files ----------------------+----------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 12 07:55:17 2008 From: trac at galois.com (GHC) Date: Mon May 12 07:49:16 2008 Subject: [GHC] #1861: Uncompilable code generated In-Reply-To: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> References: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> Message-ID: <053.66b3edfa329a3fd95bb028f1737be8a5@localhost> #1861: Uncompilable code generated ----------------------+----------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by simonmar): To merge: {{{ Mon May 12 03:38:47 PDT 2008 Simon Marlow * FIX #1861: floating-point constants for infinity and NaN in via-C }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 12 07:55:36 2008 From: trac at galois.com (GHC) Date: Mon May 12 07:49:37 2008 Subject: [GHC] #1861: Uncompilable code generated In-Reply-To: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> References: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> Message-ID: <053.b8cd5cf282848fbbe0951ab2a2ca3ca9@localhost> #1861: Uncompilable code generated ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 12 07:58:16 2008 From: trac at galois.com (GHC) Date: Mon May 12 07:52:07 2008 Subject: [GHC] #2234: Profiled binaries create empty files In-Reply-To: <044.7102554d75e5a8588c921a04c46a11b1@localhost> References: <044.7102554d75e5a8588c921a04c46a11b1@localhost> Message-ID: <053.51c68668828ebbe7f358bccba21158a8@localhost> #2234: Profiled binaries create empty files ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: low | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: To merge: {{{ Mon May 12 03:40:20 PDT 2008 Simon Marlow * FIX #2234: don't generate .prof unless we're going to put something in it }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 12 09:19:27 2008 From: trac at galois.com (GHC) Date: Mon May 12 09:13:16 2008 Subject: [GHC] #2140: cpuTimePrecision is wrong for me on Windows (XP) In-Reply-To: <044.c00dea462eff931d52d78fdca8894af2@localhost> References: <044.c00dea462eff931d52d78fdca8894af2@localhost> Message-ID: <053.7a0f4d3394bce811fbcde7d876d34603@localhost> #2140: cpuTimePrecision is wrong for me on Windows (XP) ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Windows | ----------------------------+----------------------------------------------- Comment (by guest): I use getCPUTime to measure the start and end times of some code I want to benchmark and need to know cpuTimePrecision to ensure that time quantisation is not a significant source of error and to normalise the times to some grokable number of "ticks". I don't know what part of windows API should be used for this, but 15.625 mS seems too coarse resolution (at least 4 orders of magnitude too coarse assuming a non-brain dead OS) and the figure given by cpuTimePrecision is in any case wrong. If it can't be made right then it would be better not to have it at all, or have some function which determines it empirically (you could use unsafePerformIO to keep the existing API I guess). Unfortunately the mess that is MSDN doesn't make it at all easy to figure out what can or should be done about this. I can't figure it out but perhaps someone else knows. The queryPerformanceFrequency and queryPerformanceCounter functions seem to offer better resolution, but AFAICT measure "wall clock" time rather than CPU time and may not be available on all windows systems (according to MSDN). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 12 10:33:07 2008 From: trac at galois.com (GHC) Date: Mon May 12 10:26:57 2008 Subject: [GHC] #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc In-Reply-To: <050.7b39faa855e94ccd0c6858657071f62f@localhost> References: <050.7b39faa855e94ccd0c6858657071f62f@localhost> Message-ID: <059.b0b10953deb2ce6327024f60f98a50f2@localhost> #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: This bug was fixed by this patch, which wasn't merged AFAICS. We might as well merge it, I think: {{{ Thu Feb 28 11:16:31 GMT 2008 Simon Marlow * Enable -prof -threaded (#886) }}} Thorkil, could you verify that the patch fixes the problem for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 12 14:10:11 2008 From: trac at galois.com (GHC) Date: Mon May 12 14:04:03 2008 Subject: [GHC] #1800: Template Haskell support for running functions defined in the same module In-Reply-To: <046.b7ebbbf4b1c0103c70b5120f313233b6@localhost> References: <046.b7ebbbf4b1c0103c70b5120f313233b6@localhost> Message-ID: <055.1062c549d5f7a40c3c0b3a7dcc817ebc@localhost> #1800: Template Haskell support for running functions defined in the same module ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by fons): Replying to [comment:1 simonpj]: > Here's why it's hard. It involves compiling the functions ''before'' the splice to bytecode, so that they can be run. But we don't always want to do that! Due to the additional overhead I presume... > So the trickiness is simply the plumbing required to notice that f is called from inside a splice, so we'd better compile it to bytecode early. Oh, and the transitive closure of things called by f. I'm not an GHC-expert at all, but, at the risk of not understanding a single word of your answer, can I ask why would it be so difficult to obtain the dependencies of each splice? > A possible approximation is: see if ''anything'' defined in this module is called from within a splice, and if so compile ''everything'' to bytecode, just in case. Others might not agree, but at least for me, the lack of the feature requested in this ticket is the biggest practical limitation of Template Haskell. I ignore what overhead can cause the approximation proposed above, but It would maybe be a good idea to implement it until a better solution is found. Depending on the extend in which compilation-speed is affected, it would even be a good idea to only provide this feature through a compiler- flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 12 14:20:23 2008 From: trac at galois.com (GHC) Date: Mon May 12 14:14:13 2008 Subject: [GHC] #1831: reify never provides the declaration of variables In-Reply-To: <044.a26292943bffdeb4bdb3ded03525ce1f@localhost> References: <044.a26292943bffdeb4bdb3ded03525ce1f@localhost> Message-ID: <053.aa0ac983692ac63438372287c91f44b8@localhost> #1831: reify never provides the declaration of variables ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by fons): Just for the record, this haskell-cafe message [1] shows that bundling the source info in interface files can be useful for other things than Template Haskell: ''Yes, an almost-universal printer would be possible now that we have data constructor names attached to info tables. I'd sort of planned to do that, and then got side-tracked. Of course, this won't be able to print functions in any helpful way, unless we attach source code information to functions as well (which may be worth doing anyway?).'' [1] http://www.haskell.org/pipermail/glasgow-haskell- users/2008-April/014638.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 12 15:24:21 2008 From: trac at galois.com (GHC) Date: Mon May 12 15:18:12 2008 Subject: [GHC] #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc In-Reply-To: <050.7b39faa855e94ccd0c6858657071f62f@localhost> References: <050.7b39faa855e94ccd0c6858657071f62f@localhost> Message-ID: <059.009b8a5c5130e4ae077cc1085b24a46a@localhost> #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------------+----------------------------------------------- Comment (by thorkilnaur): The problem has been fixed, thanks: Using a recent HEAD that includes the mentioned patch, I am no longer able to produce the error reaction. And notice also that the test cases that failed with this symptom {{{ ffi002(threaded1) hpc001(threaded1) hpc_fork(threaded1) tough(threaded1) }}} now succeed with the HEAD (http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20head/builds/188/steps/runtestsuite/logs/summary) whereas they still fail with STABLE (http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20stable/builds/59/steps/runtestsuite/logs/summary). Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 12 20:36:56 2008 From: trac at galois.com (GHC) Date: Mon May 12 20:30:47 2008 Subject: [GHC] #2277: GHCi silently aborts on 'take' computation In-Reply-To: <046.02df5e44a831fb20777998dee9adae29@localhost> References: <046.02df5e44a831fb20777998dee9adae29@localhost> Message-ID: <055.d020525c49166ef3d6f7fb69c4b26baf@localhost> #2277: GHCi silently aborts on 'take' computation ---------------------+------------------------------------------------------ Reporter: cdsmith | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Changes (by cdsmith): * status: new => closed * resolution: => invalid Comment: Found the problem. Ubuntu has two different packages that install a libeditline. If I add the wrong one, then GHCi aborts after any command that has a lot of output. If I remove that and use only the libeditline package marked as "supported", then it works. So this is probably not a GHC bug. I'm resolving as invalid. If that's not the right thing to do, someone let me know. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 12 20:38:45 2008 From: trac at galois.com (GHC) Date: Mon May 12 20:32:33 2008 Subject: [GHC] #2277: GHCi silently aborts on 'take' computation In-Reply-To: <046.02df5e44a831fb20777998dee9adae29@localhost> References: <046.02df5e44a831fb20777998dee9adae29@localhost> Message-ID: <055.cd88aaaf0de348c0eb87f82792431096@localhost> #2277: GHCi silently aborts on 'take' computation ---------------------+------------------------------------------------------ Reporter: cdsmith | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Changes (by cdsmith): * status: closed => reopened * resolution: invalid => Comment: Oops, not true. No, the problem still happens. But it appears to be intermittent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 13 01:00:23 2008 From: trac at galois.com (GHC) Date: Tue May 13 00:54:17 2008 Subject: [GHC] #2279: Include library source code in distribution Message-ID: <044.1391babab48570645bd5941febf460c2@localhost> #2279: Include library source code in distribution --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Component: Documentation Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple --------------------------------+------------------------------------------- I suggest including source code for haskell libraries in the distribution (or to have additional distribution with sources). The source code would be a valuable learning resource for those who are starting to learn haskell. It would be possible to examine what the function actually does. And it would be possible to replicate a patterns from the library in own code when the library functions or types do not provide a requested functionality. Even simply providing the source code would be a great help. The partially provided source for core Java libraries was one of the reasons why Java has gained popularity so fast. But providing an easy ability to recompile haskell library sources on the spot will simplify a process of submitting small enhancements and bug-fixes and it will be more in the spirit of open source. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 13 04:55:09 2008 From: trac at galois.com (GHC) Date: Tue May 13 04:48:59 2008 Subject: [GHC] #1800: Template Haskell support for running functions defined in the same module In-Reply-To: <046.b7ebbbf4b1c0103c70b5120f313233b6@localhost> References: <046.b7ebbbf4b1c0103c70b5120f313233b6@localhost> Message-ID: <055.76473f0d7d432647cc2fff32bac8ba81@localhost> #1800: Template Haskell support for running functions defined in the same module ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by simonpj): Replying to [comment:4 fons]: > Others might not agree, but at least for me, the lack of the feature requested in this ticket is the biggest practical limitation of Template Haskell. I rather agree -- that's why I created the ticket. But, even with a brutal compile-everything approach it's not straightforward to implement this feature. At the moment there is no plumbing to feed stuff right through the code generator before type checking is complete. Monomorphism makes it more complicated: consider {{{ n = 45 + 23 ... x = n + 1 ::Int }}} Today, `n`'s (monomorphic) type is resolved to `Int`, but only at the end of the module; until then we can't generate code for it. Nothing really difficult, but these tiresome interactions take time to think through and resolve. Meanwhile, folks, if you care about this feature, add yourselves to the cc list. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 13 08:56:56 2008 From: trac at galois.com (GHC) Date: Tue May 13 08:50:49 2008 Subject: [GHC] #2014: getLinkDeps panic In-Reply-To: <043.959b8170a1a6ec2b7cea0d1cfc8fd3ff@localhost> References: <043.959b8170a1a6ec2b7cea0d1cfc8fd3ff@localhost> Message-ID: <052.2e696a1d6e39b2c9b6014696f3f325f9@localhost> #2014: getLinkDeps panic ----------------------+----------------------------------------------------- Reporter: fons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): Here's a small testcase: A.hs-boot: {{{ module A where }}} A.hs: {{{ module A where }}} B.hs: {{{ module B where import {-# SOURCE #-} A () import Language.Haskell.TH expQ :: ExpQ expQ = [| () |] }}} C.hs: {{{ module C where import B foo :: a foo = undefined where second = $( expQ ) }}} Gives: {{{ ghc -Wall -fglasgow-exts -fth -c A.hs-boot ghc -Wall -fglasgow-exts -fth -c A.hs ghc -Wall -fglasgow-exts -fth -c B.hs ghc -Wall -fglasgow-exts -fth -c C.hs Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. ghc-6.9.20080511: panic! (the 'impossible' happened) (GHC version 6.9.20080511 for i386-unknown-linux): getLinkDeps No iface for main:A Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 13 09:00:42 2008 From: trac at galois.com (GHC) Date: Tue May 13 08:54:30 2008 Subject: [GHC] #2280: randomR too slow Message-ID: <044.75ca98f08f0049c4dec831e20365816b@localhost> #2280: randomR too slow -----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: libraries/random Version: 6.8.2 | Severity: normal Keywords: randomR | Testcase: Architecture: x86 | Os: Linux -----------------------------------------+---------------------------------- randomR is considerably slower than implementing it manually. Maybe I have not re-implemented it precisely, maybe it is just not inlined. {{{ module Main (main) where import System.Random (RandomGen(..), randomR, ) import qualified Data.ByteString as B newtype KnuthRandomGen = KnuthRandomGen Int {-# INLINE knuthFactor #-} knuthFactor :: Int knuthFactor = 40692 {-# INLINE knuthModulus #-} knuthModulus :: Int knuthModulus = 2^(31::Int)-249 -- we have to split the 32 bit integer in order to avoid overflow on multiplication knuthSplit :: Int knuthSplit = succ $ div knuthModulus knuthFactor knuthSplitRem :: Int knuthSplitRem = knuthSplit * knuthFactor - knuthModulus instance RandomGen KnuthRandomGen where {-# INLINE next #-} next (KnuthRandomGen s) = -- efficient computation of @mod (s*knuthFactor) knuthModulus@ without Integer let (sHigh, sLow) = divMod s knuthSplit in (s, KnuthRandomGen $ flip mod knuthModulus $ knuthSplitRem*sHigh + knuthFactor*sLow) {-# INLINE split #-} split (KnuthRandomGen s) = (KnuthRandomGen (s*s), KnuthRandomGen (13+s)) {-# INLINE genRange #-} genRange _ = (1, pred knuthModulus) main :: IO () main = do -- for comparison: that's very fast putStrLn "constant" B.writeFile "random.out" $ fst $ B.unfoldrN 10000000 (\g0@(KnuthRandomGen s) -> Just (fromIntegral s, g0)) (KnuthRandomGen 1) -- 3 seconds on my machine putStrLn "immediate" B.writeFile "random.out" $ fst $ B.unfoldrN 10000000 (\g0 -> let (w,g1) = next g0 in Just (fromIntegral (mod w 256), g1)) (KnuthRandomGen 1) -- 10 seconds on my machine putStrLn "randomR" B.writeFile "random.out" $ fst $ B.unfoldrN 10000000 (\g0 -> Just (let (w,g1) = randomR (0,255) g0 in (fromIntegral (w::Int), g1))) (KnuthRandomGen 1) {- ghc -o dist/build/randomtest -O -Wall -package bytestring-0.9.0.5 -ddump- simpl-iterations speedtest/RandomTest.hs -} {- bytestring-0.9.0.1 as shipped with GHC-6.8.2 does not inline Data.ByteString.unfoldrN -} }}} Is this related to Ticket 427? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 13 09:54:23 2008 From: trac at galois.com (GHC) Date: Tue May 13 09:48:10 2008 Subject: [GHC] #2281: properFraction implemented with modf primitive? Message-ID: <044.76024905950f1c976abf1516a4afff90@localhost> #2281: properFraction implemented with modf primitive? -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- I need a fast 'fraction' function for Double. I can use 'properFraction', but its Double instance uses 'decodeFloat', which is rather slow. It's also clumsy to use, because I have to provide an Integral type, although I'm not interested in the integral part. I can use (x - int2Double (double2Int x)) but this fails for x beyond the Int number range, and it is hard to fix that for an unknown implementation of Double. What about a 'modf' primitive which either calls 'modf' from standard C library or invokes an appropriate FPU command? If Double is in IEEE format the 'fraction' command could also be implemented quite efficiently by some bit masking without the FPU. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 13 11:33:53 2008 From: trac at galois.com (GHC) Date: Tue May 13 11:27:46 2008 Subject: [GHC] #1641: Binders generated by instance deriving are affected by -auto-all In-Reply-To: <045.bc1ef364192e47328bae6a907ad26026@localhost> References: <045.bc1ef364192e47328bae6a907ad26026@localhost> Message-ID: <054.5e3eea0c22afbe8fd47a7421162d39b0@localhost> #1641: Binders generated by instance deriving are affected by -auto-all ----------------------+----------------------------------------------------- Reporter: sorear | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: To merge: {{{ Tue May 13 01:44:00 PDT 2008 Simon Marlow * FIX #1641: don't add auto sccs to compiler-generated bindings }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 13 11:36:48 2008 From: trac at galois.com (GHC) Date: Tue May 13 11:30:57 2008 Subject: [GHC] #2282: threaded runtime system crashes on powerpc with -N2 Message-ID: <068.a075e93dacb792d84b85e8eb8eea3deb@localhost> #2282: threaded runtime system crashes on powerpc with -N2 ----------------------------------------------+----------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: powerpc | Os: MacOS X ----------------------------------------------+----------------------------- A program using threads (in a somewhat naive way) crashes at runtime, only if it is linked against the -threaded RTS, only if it is given the runtime option +RTS -N2 -RTS, and only on powerpc. The error is: {{{ SurfaceViewer: internal error: END_TSO_QUEUE object entered! (GHC version 6.8.2 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap }}} To reproduce: {{{ darcs get http://www.cs.york.ac.uk/fp/darcs/CaseTables curl -O http://www.gris.uni- tuebingen.de/edu/areas/scivis/volren/datasets/data/lobster.raw.gz gunzip lobster.raw.gz cd CaseTables ghc-6.8.2 --make -O2 -fglasgow-exts -threaded SurfaceViewer ./SurfaceViewer ../lobster.raw 301 324 56 20 1 +RTS -N2 -RTS }}} If you omit the -threaded linking flag, or omit the -N2 runtime flag, then there is no crash. I could not reproduce it on x86. The only usage of threading is in the module Gridiness, which defines a simple read/writer protocol through a Chan. A different runtime crash is apparent if the bottom three definitions in Gridiness are swapped for the top three (currently commented out), which use a single MVar for communication rather than a Chan. In that case, the error is {{{ SurfaceViewer: thread blocked indefinitely }}} The same conditions apply: must be -threaded, must have -N2, must be on powerpc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 13 11:43:26 2008 From: trac at galois.com (GHC) Date: Tue May 13 11:37:16 2008 Subject: [GHC] #2281: properFraction implemented with modf primitive? In-Reply-To: <044.76024905950f1c976abf1516a4afff90@localhost> References: <044.76024905950f1c976abf1516a4afff90@localhost> Message-ID: <053.0d070b4c990c03a39d0bac509560344a@localhost> #2281: properFraction implemented with modf primitive? -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- Comment (by dons): Can you use modf from the cmath library? http://hackage.haskell.org/packages/archive/cmath/0.3/doc/html/Foreign-C -Math-Double.html#v%3Amodf for your immediate use case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 13 14:08:25 2008 From: trac at galois.com (GHC) Date: Tue May 13 14:02:37 2008 Subject: [GHC] #2281: properFraction implemented with modf primitive? In-Reply-To: <044.76024905950f1c976abf1516a4afff90@localhost> References: <044.76024905950f1c976abf1516a4afff90@localhost> Message-ID: <053.fc5f82449afd8fa7f282a32f2e419bd1@localhost> #2281: properFraction implemented with modf primitive? -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- Comment (by guest): Thanks for the pointer. Currently I'm using '(x - int2Double (double2Int x))' since I expect it's the fastest. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 13 23:57:55 2008 From: trac at galois.com (GHC) Date: Tue May 13 23:52:00 2008 Subject: [GHC] #2282: threaded runtime system crashes on powerpc with -N2 In-Reply-To: <068.a075e93dacb792d84b85e8eb8eea3deb@localhost> References: <068.a075e93dacb792d84b85e8eb8eea3deb@localhost> Message-ID: <077.86bcab18fdba8ef96013f5e0ead837c9@localhost> #2282: threaded runtime system crashes on powerpc with -N2 ----------------------------------------------+----------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: powerpc | Os: MacOS X ----------------------------------------------+----------------------------- Comment (by thorkilnaur): Attempting to reproduce, I run into a darcs error probably caused by: {{{ $ wget -x http://www.cs.york.ac.uk/fp/darcs/CaseTables/_darcs/patches/20080513151258 -6871e-5c20436f99b8e3b17bab6771995e4e8c9552978f.gz --05:57:04-- http://www.cs.york.ac.uk/fp/darcs/CaseTables/_darcs/patches/20080513151258 -6871e-5c20436f99b8e3b17bab6771995e4e8c9552978f.gz => `www.cs.york.ac.uk/fp/darcs/CaseTables/_darcs/patches/20080513151258 -6871e-5c20436f99b8e3b17bab6771995e4e8c9552978f.gz' Resolving www.cs.york.ac.uk... 144.32.40.18 Connecting to www.cs.york.ac.uk|144.32.40.18|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 05:57:04 ERROR 403: Forbidden. }}} Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 04:06:12 2008 From: trac at galois.com (GHC) Date: Wed May 14 03:59:56 2008 Subject: [GHC] #2273: inlining defeats seq In-Reply-To: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> References: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> Message-ID: <053.0b61534871a6b3b707b55a6cb357cb9e@localhost> #2273: inlining defeats seq ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): Thanks Ian -- nice report. What is happening is this. After inlining seq we get something like this: {{{ let level = case x of { A -> 1; B -> 2 } in case level of { _ -> ...level... } }}} Now GHC thinks that the case-expression for `level` is cheap (which it is), and therefore ok to duplicate, so it inlines it {{{ let level = case x of { A -> 1; B -> 2 } in case (case x of { A -> 1; B -> 2 }) of { _ -> ...level... } }}} Now there's only one remaining occurrence of `level` so that gets inlined too. Disaster. This example has made me realise that what is ''really'' wrong here is that `seq` should really have a type more like {{{ fseq :: a -> (a -> b) -> b }}} Then we'd have {{{ level `fseq` (\level -> ...level...) }}} Now the inner `level` is nothing to do with the outer `level` and all will be well. So here we are saying what we mean: "evaluate `level` and use the evaluated version inside here". This version of `seq` is just reversed strict function application, of course. Which is very like strict `let`. So with bang patterns we could also write {{{ let !level2 = level in ...level2... }}} This is satisfactorily explicit, but we must use a new name (`level2`). Perhaps that's not unreasonable. Both `fseq` and a strict let could desugar to {{{ case level of level2 { _ -> ...level2... } }}} Meanwhile I think a good fix will be to change the desugarer to desugar saturated applications of `seq` to this same form. Not very robust to abstraction, but better than what we have now. `seq` is subtler than it looks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 05:48:51 2008 From: trac at galois.com (GHC) Date: Wed May 14 05:42:36 2008 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols Message-ID: <047.9dd077e0a526e115792cbcdfa56aeafb@localhost> #2283: WIndows: loading objects that refer to DLL symbols -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- This is a test case from #1288, distilled into a separate report so I can close #1288: `test3b.c`: {{{ #include __declspec(dllexport) void _stdcall test(int arg) { printf("The argument passed was %i\n", arg ); } }}} `test_proxy_5a.c`: {{{ __declspec(dllimport) void _stdcall test(int arg); void test_proxy(int arg) { test(arg); } }}} To reproduce: {{{ gcc -c test3b.c ar -rv test3b.a test3b.o c:/mingw/bin/dllwrap --export-all-symbols --output-lib test3b.dll.a -o test3b.dll test3b.a gcc -c test_proxy_5a.c ghci -ltest3b test_proxy_5a.o }}} the error message we get: {{{ GHCi, version 6.9.20080512: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading object (static) test_proxy_5a.o ... done Loading object (dynamic) test3b ... done ghc.exe: test_proxy_5a.o: unknown symbol `__imp__test' final link ... ghc.exe: linking extra libraries/objects failed }}} I'm not sure to what extent we need to support this, it's possible to link to the DLL by omitting the dllimport declaration. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 06:20:33 2008 From: trac at galois.com (GHC) Date: Wed May 14 06:14:35 2008 Subject: [GHC] #2282: threaded runtime system crashes on powerpc with -N2 In-Reply-To: <068.a075e93dacb792d84b85e8eb8eea3deb@localhost> References: <068.a075e93dacb792d84b85e8eb8eea3deb@localhost> Message-ID: <077.38c69292504d18374b6024384eb9dcd6@localhost> #2282: threaded runtime system crashes on powerpc with -N2 -------------------------------------------+-------------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------------------------+-------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: It might be a while before we can track down this bug, and I assume that the darcs repository will change in the future. Malcolm, could you tar up the exact source tree used to reproduce the bug and attach it to this ticket? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 06:15:44 2008 From: trac at galois.com (GHC) Date: Wed May 14 06:15:47 2008 Subject: [GHC] #2257: validate hangs in configure In-Reply-To: <041.16fba6c404adcf566b7f71a6b9078150@localhost> References: <041.16fba6c404adcf566b7f71a6b9078150@localhost> Message-ID: <050.072224f5fc1707e21d1c6fed77ff6d99@localhost> #2257: validate hangs in configure --------------------------+------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: highest | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Comment (by simonmar): I don't have any machines that exhibit this behaviour. Can anyone help? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 06:28:58 2008 From: trac at galois.com (GHC) Date: Wed May 14 06:23:00 2008 Subject: [GHC] #2282: threaded runtime system crashes on powerpc with -N2 In-Reply-To: <068.a075e93dacb792d84b85e8eb8eea3deb@localhost> References: <068.a075e93dacb792d84b85e8eb8eea3deb@localhost> Message-ID: <077.ac3455119e45edb91524bcd726226cd4@localhost> #2282: threaded runtime system crashes on powerpc with -N2 -------------------------------------------+-------------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------------------------+-------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): Source code attached in a tarfile. The test data must still be downloaded separately, since it is too large to attach to the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 07:10:57 2008 From: trac at galois.com (GHC) Date: Wed May 14 07:04:41 2008 Subject: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 In-Reply-To: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> References: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> Message-ID: <058.1cbb283dabd7b42883055d19bf9013fc@localhost> #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 ----------------------------+----------------------------------------------- Reporter: twhitehead | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Comment (by simonmar): Sadly I have no machines with enough memory to run this program. Also, reading back through the comments apparently `Bug.hs` crashed in "an hour and three quarters", which would make it quicker than the 3hrs 10min for `Bug2.hs`, right? Unfortunately from the memory leak message, it seems like the RTS had been using around 13Gb at the time, which is way more than I have in any of my machines. I'll look into getting a new machine, or some more memory. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 08:08:42 2008 From: trac at galois.com (GHC) Date: Wed May 14 08:02:26 2008 Subject: [GHC] #2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid argument (Invalid argument)" In-Reply-To: <045.9f2f177f681138fbf7d90d1273238fd5@localhost> References: <045.9f2f177f681138fbf7d90d1273238fd5@localhost> Message-ID: <054.6a73d734593f1a3c16d0fc5d14c003d4@localhost> #2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid argument (Invalid argument)" -----------------------------------+---------------------------------------- Reporter: slyfox | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: libraries/unix | Version: 6.8.2 Severity: major | Resolution: Keywords: regression, ffi, unix | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -----------------------------------+---------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 08:20:21 2008 From: trac at galois.com (GHC) Date: Wed May 14 08:14:05 2008 Subject: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!! In-Reply-To: <057.ee3a70497de9cc3d83abf1aab5293225@localhost> References: <057.ee3a70497de9cc3d83abf1aab5293225@localhost> Message-ID: <066.d738c365e2150152c8d21fca6b0f7c7c@localhost> #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!! -------------------------------------------------+-------------------------- Reporter: jvlask@hotmail.com | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.6 Severity: critical | Resolution: Keywords: ghci foreign ffi dll import stdcall | Difficulty: Moderate (1 day) Testcase: | Architecture: x86 Os: Windows | -------------------------------------------------+-------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: One bug fixed, remaining bug moved to #2283 To merge: {{{ Wed May 14 02:27:42 PDT 2008 Simon Marlow * FIX #1288: GHCi wasn't adding the @n suffix to stdcalls on Windows }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 08:20:47 2008 From: trac at galois.com (GHC) Date: Wed May 14 08:14:30 2008 Subject: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!! In-Reply-To: <057.ee3a70497de9cc3d83abf1aab5293225@localhost> References: <057.ee3a70497de9cc3d83abf1aab5293225@localhost> Message-ID: <066.0968e626a994210335ce858a91737b64@localhost> #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!! -------------------------------------------------+-------------------------- Reporter: jvlask@hotmail.com | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.6 Severity: critical | Resolution: Keywords: ghci foreign ffi dll import stdcall | Difficulty: Moderate (1 day) Testcase: | Architecture: x86 Os: Windows | -------------------------------------------------+-------------------------- Changes (by simonmar): * milestone: 6.10 branch => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 08:24:58 2008 From: trac at galois.com (GHC) Date: Wed May 14 08:18:43 2008 Subject: [GHC] #2276: foreign import stdcall "&foo" doesn't work In-Reply-To: <047.799717800ba2c37716201ce0aa31af44@localhost> References: <047.799717800ba2c37716201ce0aa31af44@localhost> Message-ID: <056.77c900ae5553374991b318dfa1e686a1@localhost> #2276: foreign import stdcall "&foo" doesn't work ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge * milestone: _|_ => 6.8.3 Comment: Fixed. This can be merged, but omitting the changes to PprC and CLabel which aren't necessary on the stable branch. {{{ Wed May 14 01:24:22 PDT 2008 Simon Marlow * FIX #2276: foreign import stdcall "&foo" doesn't work }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 09:08:17 2008 From: trac at galois.com (GHC) Date: Wed May 14 09:01:59 2008 Subject: [GHC] #2275: Poor indication of type error location In-Reply-To: <044.43d81bf78db38afe22fab3304ba5b342@localhost> References: <044.43d81bf78db38afe22fab3304ba5b342@localhost> Message-ID: <053.1c73c962c9ba891b89b32e0a0d29e338@localhost> #2275: Poor indication of type error location -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by simonpj): I can't say I understand just what's going on here. It's difficult to fix this unless we can reproduce it, but you don't give enough information to do that. If you have enough time to upload a reproducible test case, that'd be great. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 11:23:22 2008 From: trac at galois.com (GHC) Date: Wed May 14 11:17:05 2008 Subject: [GHC] #2284: Stack-hack optimization causes much re-computation in GUI callbacks Message-ID: <048.962fc54d8c39b16cf1f38c360fbbf18e@localhost> #2284: Stack-hack optimization causes much re-computation in GUI callbacks --------------------------+------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Multiple --------------------------+------------------------------------------------- This is a duplicate of #1168, recorded for posterity here, at the request of Simon PJ, http://www.haskell.org/pipermail/glasgow-haskell- users/2008-May/014739.html An IO lambda is created within main's scope, and this is given to the GLUT GUI library (or it could be GTK or wxHaskell) as a callback to draw the contents of the window. The callback lambda captures a value from the outer scope, but the state-hack inlines the value's defining expression into the callback. Thus, the value is re-computed every time the callback is called. -fno-state-hack fixes it. The attached program is a 3D model viewer. I've attached two models, one is small, the other larger. The performance hit is quite noticeable on the large one. The models need to be unzipped before running. {{{ gunzip torus.obj.gz ./ObjView torus.obj }}} use x y z to rotate and force a redraw. When compiled with -O0 or -fno- state-hack, you'll see "BUILDING MESH" output once, otherwise it will be output on every redraw. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 11:24:49 2008 From: trac at galois.com (GHC) Date: Wed May 14 11:18:43 2008 Subject: [GHC] #2285: Solaris 9 build fails at stage2 with undefined symbol errors (for libm symbols) Message-ID: <048.9d281a64a969b94451f675cf7f831df1@localhost> #2285: Solaris 9 build fails at stage2 with undefined symbol errors (for libm symbols) --------------------------+------------------------------------------------- Reporter: TimBishop | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: sparc | Os: Solaris --------------------------+------------------------------------------------- (A copy of the pasted errors is attached to the ticket) I'm having a problem building ghc 6.8.2 using gcc 4.2.3 on Solaris 9. The problem occurs during the linking of stage2/ghc-inplace. Here is the error: {{{ make[3]: Entering directory `/u1/src/garstow/devel/ghc/work/ghc-6.8.2/compiler' ../compiler/stage1/ghc-inplace -cpp stage2/ghc-inplace.c -o stage2/ghc- inplace Undefined first referenced symbol in file cosf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) expf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) logf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) powf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) sinf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) tanf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) acosf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) asinf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) atanf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) coshf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) sinhf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) tanhf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) sqrtf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) ld: fatal: Symbol referencing errors. No output written to stage2/ghc- inplace collect2: ld returned 1 exit status make[3]: *** [stage2/ghc-inplace] Error 1 make[3]: Leaving directory `/u1/src/garstow/devel/ghc/work/ghc-6.8.2/compiler' make[2]: *** [stage2] Error 2 make[2]: Leaving directory `/u1/src/garstow/devel/ghc/work/ghc-6.8.2' make[1]: *** [bootstrap2] Error 2 make[1]: Leaving directory `/u1/src/garstow/devel/ghc/work/ghc-6.8.2' make: *** [build-work/ghc-6.8.2/Makefile] Error 2 }}} It was fairly obvious those symbols were provided by libm, so I did a little digging to check if it was trying to link -lm, and it was: {{{ tdb@vulture [/u1/src/garstow/devel/ghc/work/ghc-6.8.2/compiler] % ../compiler/stage1/ghc-inplace -v -cpp stage2/ghc-inplace.c -o stage2/ghc- inplace Using /u1/src/garstow/devel/ghc/work/ghc-6.8.2/compiler/stage1/ghc-6.8.2 -B/u1/src/garstow/devel/ghc/work/ghc-6.8.2 -fhardwire-lib-paths Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 1 booted by GHC version 6.4.1 Using package config file: /u1/src/garstow/devel/ghc/work/ghc-6.8.2/driver/package.conf.inplace wired-in package base mapped to base-3.0.1.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package template-haskell mapped to template-haskell-2.2.0.0 wired-in package ndp not found. Hsc static flags: -fhardwire-lib-paths -static Created temporary directory: /tmp/ghc6599_0 *** C Compiler: gcc -x c stage2/ghc-inplace.c -o /tmp/ghc6599_0/ghc6599_0.s -mcpu=v9 -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=608 -DTABLES_NEXT_TO_CODE -I /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/include -I /u1/src/garstow/devel/ghc/work/ghc-6.8.2/includes -I /u1/src/garstow/devel/ghc/work/ghc-6.8.2/rts -I /u1/src/garstow/devel/ghc/work/ghc-6.8.2/gmp/gmpbuild Using built-in specs. Target: sparc-sun-solaris2.9 Configured with: ../../work/gcc-4.2.3/configure --enable-threads --enable- shared=libstdc++ --enable- languages=ada,c,c++,fortran,java,objc,obj-c++,treelang --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld Thread model: posix gcc version 4.2.3 /usr/local/packages/gcc-4.2.3/bin/../libexec/gcc/sparc-sun- solaris2.9/4.2.3/cc1 -quiet -v -I /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/include -I /u1/src/garstow/devel/ghc/work/ghc-6.8.2/includes -I /u1/src/garstow/devel/ghc/work/ghc-6.8.2/rts -I /u1/src/garstow/devel/ghc/work/ghc-6.8.2/gmp/gmpbuild -iprefix /usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun-solaris2.9/4.2.3/ -D__sparcv8 -D__GLASGOW_HASKELL__=608 -DTABLES_NEXT_TO_CODE stage2/ghc- inplace.c -quiet -dumpbase ghc-inplace.c -mcpu=v9 -auxbase-strip /tmp/ghc6599_0/ghc6599_0.s -O -Wimplicit -version -o /tmp/ghc6599_0/ghc6599_0.s ignoring nonexistent directory "/usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun-solaris2.9/4.2.3 /../../../../sparc-sun-solaris2.9/include" ignoring nonexistent directory "NONE/include" ignoring duplicate directory "/usr/local/lib/gcc/sparc-sun- solaris2.9/4.2.3/include" ignoring nonexistent directory "/usr/local/lib/gcc/sparc-sun- solaris2.9/4.2.3/../../../../sparc-sun-solaris2.9/include" ignoring nonexistent directory "/u1/src/garstow/devel/ghc/work/ghc-6.8.2/gmp/gmpbuild" #include "..." search starts here: #include <...> search starts here: /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/include /u1/src/garstow/devel/ghc/work/ghc-6.8.2/includes /u1/src/garstow/devel/ghc/work/ghc-6.8.2/rts /usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun- solaris2.9/4.2.3/include /usr/local/include /usr/include End of search list. GNU C version 4.2.3 (sparc-sun-solaris2.9) compiled by GNU C version 4.2.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 71a7bcafd96401b66a893845012cdee8 *** Assembler: gcc -mcpu=v9 -c /tmp/ghc6599_0/ghc6599_0.s -o stage2/ghc-inplace.o *** Linker: gcc -v -o stage2/ghc-inplace stage2/ghc-inplace.o -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/haskell98/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/array/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/process/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/unix/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/random/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/directory/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/filepath/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/old-time/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/old-locale/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/rts -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/gmp -lHShaskell98-1.0.1.0 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSunix-2.3.0.0 -ldl -lHSrandom-1.0.0.0 -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold- time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSbase-3.0.1.0 -lHSrts -lm -lgmp -ldl -lrt -u base_GHCziBase_Izh_static_info -u base_GHCziBase_Czh_static_info -u base_GHCziFloat_Fzh_static_info -u base_GHCziFloat_Dzh_static_info -u base_GHCziPtr_Ptr_static_info -u base_GHCziWord_Wzh_static_info -u base_GHCziInt_I8zh_static_info -u base_GHCziInt_I16zh_static_info -u base_GHCziInt_I32zh_static_info -u base_GHCziInt_I64zh_static_info -u base_GHCziWord_W8zh_static_info -u base_GHCziWord_W16zh_static_info -u base_GHCziWord_W32zh_static_info -u base_GHCziWord_W64zh_static_info -u base_GHCziStable_StablePtr_static_info -u base_GHCziBase_Izh_con_info -u base_GHCziBase_Czh_con_info -u base_GHCziFloat_Fzh_con_info -u base_GHCziFloat_Dzh_con_info -u base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u base_GHCziStable_StablePtr_con_info -u base_GHCziBase_False_closure -u base_GHCziBase_True_closure -u base_GHCziPack_unpackCString_closure -u base_GHCziIOBase_stackOverflow_closure -u base_GHCziIOBase_heapOverflow_closure -u base_GHCziIOBase_NonTermination_closure -u base_GHCziIOBase_BlockedOnDeadMVar_closure -u base_GHCziIOBase_BlockedIndefinitely_closure -u base_GHCziIOBase_Deadlock_closure -u base_GHCziIOBase_NestedAtomically_closure -u base_GHCziWeak_runFinalizzerBatch_closure -u base_GHCziConc_ensureIOManagerIsRunning_closure Using built-in specs. Target: sparc-sun-solaris2.9 Configured with: ../../work/gcc-4.2.3/configure --enable-threads --enable- shared=libstdc++ --enable- languages=ada,c,c++,fortran,java,objc,obj-c++,treelang --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld Thread model: posix gcc version 4.2.3 /usr/local/packages/gcc-4.2.3/bin/../libexec/gcc/sparc-sun- solaris2.9/4.2.3/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -Qy -o stage2/ghc- inplace -u base_GHCziBase_Izh_static_info -u base_GHCziBase_Czh_static_info -u base_GHCziFloat_Fzh_static_info -u base_GHCziFloat_Dzh_static_info -u base_GHCziPtr_Ptr_static_info -u base_GHCziWord_Wzh_static_info -u base_GHCziInt_I8zh_static_info -u base_GHCziInt_I16zh_static_info -u base_GHCziInt_I32zh_static_info -u base_GHCziInt_I64zh_static_info -u base_GHCziWord_W8zh_static_info -u base_GHCziWord_W16zh_static_info -u base_GHCziWord_W32zh_static_info -u base_GHCziWord_W64zh_static_info -u base_GHCziStable_StablePtr_static_info -u base_GHCziBase_Izh_con_info -u base_GHCziBase_Czh_con_info -u base_GHCziFloat_Fzh_con_info -u base_GHCziFloat_Dzh_con_info -u base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u base_GHCziStable_StablePtr_con_info -u base_GHCziBase_False_closure -u base_GHCziBase_True_closure -u base_GHCziPack_unpackCString_closure -u base_GHCziIOBase_stackOverflow_closure -u base_GHCziIOBase_heapOverflow_closure -u base_GHCziIOBase_NonTermination_closure -u base_GHCziIOBase_BlockedOnDeadMVar_closure -u base_GHCziIOBase_BlockedIndefinitely_closure -u base_GHCziIOBase_Deadlock_closure -u base_GHCziIOBase_NestedAtomically_closure -u base_GHCziWeak_runFinalizzerBatch_closure -u base_GHCziConc_ensureIOManagerIsRunning_closure /usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun- solaris2.9/4.2.3/crt1.o /usr/local/packages/gcc-4.2.3/bin/../lib/gcc /sparc-sun-solaris2.9/4.2.3/crti.o /usr/ccs/lib/values-Xa.o /usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun- solaris2.9/4.2.3/crtbegin.o -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/haskell98/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/array/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/process/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/unix/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/random/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/directory/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/filepath/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/old-time/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/old-locale/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/rts -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/gmp -L/usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun-solaris2.9/4.2.3 -L/usr/local/packages/gcc-4.2.3/bin/../lib/gcc -L/usr/local/lib/gcc/sparc- sun-solaris2.9/4.2.3 -L/usr/ccs/lib -L/usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun- solaris2.9/4.2.3/../../.. -L/usr/local/lib/gcc/sparc-sun- solaris2.9/4.2.3/../../.. stage2/ghc-inplace.o -lHShaskell98-1.0.1.0 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSunix-2.3.0.0 -ldl -lHSrandom-1.0.0.0 -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold- time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSbase-3.0.1.0 -lHSrts -lm -lgmp -ldl -lrt -lgcc -lc -lgcc -lc /usr/local/packages/gcc-4.2.3/bin/../lib/gcc /sparc-sun-solaris2.9/4.2.3/crtend.o /usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun- solaris2.9/4.2.3/crtn.o ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.397 Undefined first referenced symbol in file cosf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) expf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) logf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) powf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) sinf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) tanf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) acosf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) asinf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) atanf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) coshf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) sinhf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) tanhf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) sqrtf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) ld: fatal: Symbol referencing errors. No output written to stage2/ghc- inplace collect2: ld returned 1 exit status *** Deleting temp files: Deleting: /tmp/ghc6599_0/ghc6599_0.s *** Deleting temp dirs: Deleting: /tmp/ghc6599_0 }}} I then confirmed the problem could be replicated with just gcc: {{{ tdb@vulture [/u1/src/garstow/devel/ghc/work/ghc-6.8.2/compiler] % gcc -v -o stage2/ghc-inplace stage2/ghc-inplace.o -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/haskell98/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/array/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/process/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/unix/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/random/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/directory/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/filepath/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/old-time/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/old-locale/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/rts -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/gmp -lHShaskell98-1.0.1.0 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSunix-2.3.0.0 -ldl -lHSrandom-1.0.0.0 -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold- time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSbase-3.0.1.0 -lHSrts -lm -lgmp -ldl -lrt -u base_GHCziBase_Izh_static_info -u base_GHCziBase_Czh_static_info -u base_GHCziFloat_Fzh_static_info -u base_GHCziFloat_Dzh_static_info -u base_GHCziPtr_Ptr_static_info -u base_GHCziWord_Wzh_static_info -u base_GHCziInt_I8zh_static_info -u base_GHCziInt_I16zh_static_info -u base_GHCziInt_I32zh_static_info -u base_GHCziInt_I64zh_static_info -u base_GHCziWord_W8zh_static_info -u base_GHCziWord_W16zh_static_info -u base_GHCziWord_W32zh_static_info -u base_GHCziWord_W64zh_static_info -u base_GHCziStable_StablePtr_static_info -u base_GHCziBase_Izh_con_info -u base_GHCziBase_Czh_con_info -u base_GHCziFloat_Fzh_con_info -u base_GHCziFloat_Dzh_con_info -u base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u base_GHCziStable_StablePtr_con_info -u base_GHCziBase_False_closure -u base_GHCziBase_True_closure -u base_GHCziPack_unpackCString_closure -u base_GHCziIOBase_stackOverflow_closure -u base_GHCziIOBase_heapOverflow_closure -u base_GHCziIOBase_NonTermination_closure -u base_GHCziIOBase_BlockedOnDeadMVar_closure -u base_GHCziIOBase_BlockedIndefinitely_closure -u base_GHCziIOBase_Deadlock_closure -u base_GHCziIOBase_NestedAtomically_closure -u base_GHCziWeak_runFinalizzerBatch_closure -u base_GHCziConc_ensureIOManagerIsRunning_closure Using built-in specs. Target: sparc-sun-solaris2.9 Configured with: ../../work/gcc-4.2.3/configure --enable-threads --enable- shared=libstdc++ --enable- languages=ada,c,c++,fortran,java,objc,obj-c++,treelang --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld Thread model: posix gcc version 4.2.3 /usr/local/packages/gcc-4.2.3/bin/../libexec/gcc/sparc-sun- solaris2.9/4.2.3/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -Qy -o stage2/ghc- inplace -u base_GHCziBase_Izh_static_info -u base_GHCziBase_Czh_static_info -u base_GHCziFloat_Fzh_static_info -u base_GHCziFloat_Dzh_static_info -u base_GHCziPtr_Ptr_static_info -u base_GHCziWord_Wzh_static_info -u base_GHCziInt_I8zh_static_info -u base_GHCziInt_I16zh_static_info -u base_GHCziInt_I32zh_static_info -u base_GHCziInt_I64zh_static_info -u base_GHCziWord_W8zh_static_info -u base_GHCziWord_W16zh_static_info -u base_GHCziWord_W32zh_static_info -u base_GHCziWord_W64zh_static_info -u base_GHCziStable_StablePtr_static_info -u base_GHCziBase_Izh_con_info -u base_GHCziBase_Czh_con_info -u base_GHCziFloat_Fzh_con_info -u base_GHCziFloat_Dzh_con_info -u base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u base_GHCziStable_StablePtr_con_info -u base_GHCziBase_False_closure -u base_GHCziBase_True_closure -u base_GHCziPack_unpackCString_closure -u base_GHCziIOBase_stackOverflow_closure -u base_GHCziIOBase_heapOverflow_closure -u base_GHCziIOBase_NonTermination_closure -u base_GHCziIOBase_BlockedOnDeadMVar_closure -u base_GHCziIOBase_BlockedIndefinitely_closure -u base_GHCziIOBase_Deadlock_closure -u base_GHCziIOBase_NestedAtomically_closure -u base_GHCziWeak_runFinalizzerBatch_closure -u base_GHCziConc_ensureIOManagerIsRunning_closure /usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun- solaris2.9/4.2.3/crt1.o /usr/local/packages/gcc-4.2.3/bin/../lib/gcc /sparc-sun-solaris2.9/4.2.3/crti.o /usr/ccs/lib/values-Xa.o /usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun- solaris2.9/4.2.3/crtbegin.o -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/haskell98/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/array/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/process/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/unix/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/random/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/directory/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/filepath/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/old-time/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/old-locale/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/rts -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/gmp -L/usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun-solaris2.9/4.2.3 -L/usr/local/packages/gcc-4.2.3/bin/../lib/gcc -L/usr/local/lib/gcc/sparc- sun-solaris2.9/4.2.3 -L/usr/ccs/lib -L/usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun- solaris2.9/4.2.3/../../.. -L/usr/local/lib/gcc/sparc-sun- solaris2.9/4.2.3/../../.. stage2/ghc-inplace.o -lHShaskell98-1.0.1.0 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSunix-2.3.0.0 -ldl -lHSrandom-1.0.0.0 -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold- time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSbase-3.0.1.0 -lHSrts -lm -lgmp -ldl -lrt -lgcc -lc -lgcc -lc /usr/local/packages/gcc-4.2.3/bin/../lib/gcc /sparc-sun-solaris2.9/4.2.3/crtend.o /usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun- solaris2.9/4.2.3/crtn.o ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.397 Undefined first referenced symbol in file cosf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) expf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) logf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) powf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) sinf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) tanf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) acosf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) asinf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) atanf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) coshf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) sinhf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) tanhf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) sqrtf /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o) ld: fatal: Symbol referencing errors. No output written to stage2/ghc- inplace collect2: ld returned 1 exit status }}} As a work-around I tried giving it the static libm library, and that succeeded: {{{ tdb@vulture [/u1/src/garstow/devel/ghc/work/ghc-6.8.2/compiler] % gcc -v -o stage2/ghc-inplace stage2/ghc-inplace.o -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/haskell98/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/array/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/process/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/unix/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/random/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/directory/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/filepath/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/old-time/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/old-locale/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/rts -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/gmp -lHShaskell98-1.0.1.0 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSunix-2.3.0.0 -ldl -lHSrandom-1.0.0.0 -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold- time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSbase-3.0.1.0 -lHSrts -lm -lgmp -ldl -lrt -u base_GHCziBase_Izh_static_info -u base_GHCziBase_Czh_static_info -u base_GHCziFloat_Fzh_static_info -u base_GHCziFloat_Dzh_static_info -u base_GHCziPtr_Ptr_static_info -u base_GHCziWord_Wzh_static_info -u base_GHCziInt_I8zh_static_info -u base_GHCziInt_I16zh_static_info -u base_GHCziInt_I32zh_static_info -u base_GHCziInt_I64zh_static_info -u base_GHCziWord_W8zh_static_info -u base_GHCziWord_W16zh_static_info -u base_GHCziWord_W32zh_static_info -u base_GHCziWord_W64zh_static_info -u base_GHCziStable_StablePtr_static_info -u base_GHCziBase_Izh_con_info -u base_GHCziBase_Czh_con_info -u base_GHCziFloat_Fzh_con_info -u base_GHCziFloat_Dzh_con_info -u base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u base_GHCziStable_StablePtr_con_info -u base_GHCziBase_False_closure -u base_GHCziBase_True_closure -u base_GHCziPack_unpackCString_closure -u base_GHCziIOBase_stackOverflow_closure -u base_GHCziIOBase_heapOverflow_closure -u base_GHCziIOBase_NonTermination_closure -u base_GHCziIOBase_BlockedOnDeadMVar_closure -u base_GHCziIOBase_BlockedIndefinitely_closure -u base_GHCziIOBase_Deadlock_closure -u base_GHCziIOBase_NestedAtomically_closure -u base_GHCziWeak_runFinalizzerBatch_closure -u base_GHCziConc_ensureIOManagerIsRunning_closure /usr/lib/libm.a Using built-in specs. Target: sparc-sun-solaris2.9 Configured with: ../../work/gcc-4.2.3/configure --enable-threads --enable- shared=libstdc++ --enable- languages=ada,c,c++,fortran,java,objc,obj-c++,treelang --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld Thread model: posix gcc version 4.2.3 /usr/local/packages/gcc-4.2.3/bin/../libexec/gcc/sparc-sun- solaris2.9/4.2.3/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -Qy -o stage2/ghc- inplace -u base_GHCziBase_Izh_static_info -u base_GHCziBase_Czh_static_info -u base_GHCziFloat_Fzh_static_info -u base_GHCziFloat_Dzh_static_info -u base_GHCziPtr_Ptr_static_info -u base_GHCziWord_Wzh_static_info -u base_GHCziInt_I8zh_static_info -u base_GHCziInt_I16zh_static_info -u base_GHCziInt_I32zh_static_info -u base_GHCziInt_I64zh_static_info -u base_GHCziWord_W8zh_static_info -u base_GHCziWord_W16zh_static_info -u base_GHCziWord_W32zh_static_info -u base_GHCziWord_W64zh_static_info -u base_GHCziStable_StablePtr_static_info -u base_GHCziBase_Izh_con_info -u base_GHCziBase_Czh_con_info -u base_GHCziFloat_Fzh_con_info -u base_GHCziFloat_Dzh_con_info -u base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u base_GHCziStable_StablePtr_con_info -u base_GHCziBase_False_closure -u base_GHCziBase_True_closure -u base_GHCziPack_unpackCString_closure -u base_GHCziIOBase_stackOverflow_closure -u base_GHCziIOBase_heapOverflow_closure -u base_GHCziIOBase_NonTermination_closure -u base_GHCziIOBase_BlockedOnDeadMVar_closure -u base_GHCziIOBase_BlockedIndefinitely_closure -u base_GHCziIOBase_Deadlock_closure -u base_GHCziIOBase_NestedAtomically_closure -u base_GHCziWeak_runFinalizzerBatch_closure -u base_GHCziConc_ensureIOManagerIsRunning_closure /usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun- solaris2.9/4.2.3/crt1.o /usr/local/packages/gcc-4.2.3/bin/../lib/gcc /sparc-sun-solaris2.9/4.2.3/crti.o /usr/ccs/lib/values-Xa.o /usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun- solaris2.9/4.2.3/crtbegin.o -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/haskell98/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/array/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/process/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/unix/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/random/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/directory/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/filepath/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/old-time/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/old-locale/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/rts -L/u1/src/garstow/devel/ghc/work/ghc-6.8.2/gmp -L/usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun-solaris2.9/4.2.3 -L/usr/local/packages/gcc-4.2.3/bin/../lib/gcc -L/usr/local/lib/gcc/sparc- sun-solaris2.9/4.2.3 -L/usr/ccs/lib -L/usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun- solaris2.9/4.2.3/../../.. -L/usr/local/lib/gcc/sparc-sun- solaris2.9/4.2.3/../../.. stage2/ghc-inplace.o -lHShaskell98-1.0.1.0 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSunix-2.3.0.0 -ldl -lHSrandom-1.0.0.0 -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold- time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSbase-3.0.1.0 -lHSrts -lm -lgmp -ldl -lrt /usr/lib/libm.a -lgcc -lc -lgcc -lc /usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-sun- solaris2.9/4.2.3/crtend.o /usr/local/packages/gcc-4.2.3/bin/../lib/gcc /sparc-sun-solaris2.9/4.2.3/crtn.o ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.397 }}} Strangely the resulting binary ''is'' linked against libm.so. I used truss to check if an alternate libm was being found by the compiler, but it wasn't. I also tried adding -lm to the beginning and end of the compile line, but it didn't help. I'm happy to help debug as needed. Thanks, Tim. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 11:27:37 2008 From: trac at galois.com (GHC) Date: Wed May 14 11:21:19 2008 Subject: [GHC] #2284: Stack-hack optimization causes much re-computation in GUI callbacks In-Reply-To: <048.962fc54d8c39b16cf1f38c360fbbf18e@localhost> References: <048.962fc54d8c39b16cf1f38c360fbbf18e@localhost> Message-ID: <057.7f3707d4f521d1f71dfd246245724997@localhost> #2284: Stack-hack optimization causes much re-computation in GUI callbacks --------------------------+------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Multiple --------------------------+------------------------------------------------- Comment (by sedillard): Oops the big test file is too big. You can download it here: http://graphics.cs.ucdavis.edu/~sdillard/horse.obj.gz With -O2 and -fno-state-hack it actually does quite well on my 2.1Ghz machine. Scott -- Ticket URL: GHC The Glasgow Haskell Compiler From nr at eecs.harvard.edu Wed May 14 15:26:30 2008 From: nr at eecs.harvard.edu (Norman Ramsey) Date: Wed May 14 15:20:12 2008 Subject: [GHC] #2257: validate hangs in configure In-Reply-To: <050.072224f5fc1707e21d1c6fed77ff6d99@localhost> (sfid-H-20080514-062342-+35.76-1@multi.osbf.lua) References: <041.16fba6c404adcf566b7f71a6b9078150@localhost> <050.072224f5fc1707e21d1c6fed77ff6d99@localhost> (sfid-H-20080514-062342-+35.76-1@multi.osbf.lua) Message-ID: <20080514192631.8A294E803E@jindo.eecs.harvard.edu> > #2257: validate hangs in configure > --------------------------+------------------------------------------------- > Reporter: nr | Owner: > Type: bug | Status: new > Priority: highest | Milestone: 6.8.3 > Component: Build System | Version: 6.8.2 > Severity: major | Resolution: > Keywords: | Difficulty: Unknown > Testcase: | Architecture: x86 > Os: Linux | > --------------------------+------------------------------------------------- > Comment (by simonmar): > > I don't have any machines that exhibit this behaviour. Can anyone help? Send me an ssh public key and I'll give you a login on the offending machine. Norman From trac at galois.com Wed May 14 18:10:12 2008 From: trac at galois.com (GHC) Date: Wed May 14 18:03:54 2008 Subject: [GHC] #1886: GHC API should preserve and provide access to comments In-Reply-To: <044.eac6e4e9449b44410013b3e7df813e47@localhost> References: <044.eac6e4e9449b44410013b3e7df813e47@localhost> Message-ID: <053.b5fd80f19ec7c969be275feda7e022ec@localhost> #1886: GHC API should preserve and provide access to comments ---------------------------------------------------------------+------------ Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: GHC API, comments, program transformation, layout | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------------------------------------+------------ Comment (by claus): see also this thread for a simpler breakdown of what is needed, and how it might be achieved: http://www.haskell.org/pipermail/haskell-cafe/2008-May/042671.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 20:38:37 2008 From: trac at galois.com (GHC) Date: Wed May 14 20:32:27 2008 Subject: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 In-Reply-To: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> References: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> Message-ID: <058.d9fa84fc470ceee4c9a5b0aaf83df21c@localhost> #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 ----------------------------+----------------------------------------------- Reporter: twhitehead | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Comment (by twhitehead): Bug2.hs is the 1hr-42min-to-crash code, I just made a mistake when quoting its runtime in the fastest-to-crash-code note above (I also made it somewhat confusing in the detailed messages above by always just refering to Bug.hs as I didn't actually add the extensions until I went to upload them). With regard to not having a machine with enough memory, I can get you access to our 32GiB-per-node cluster if that would help. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 14 20:48:40 2008 From: trac at galois.com (GHC) Date: Wed May 14 20:42:29 2008 Subject: [GHC] #2279: Include library source code in distribution In-Reply-To: <044.1391babab48570645bd5941febf460c2@localhost> References: <044.1391babab48570645bd5941febf460c2@localhost> Message-ID: <053.656b652359f180dbb0161d3bae467d3c@localhost> #2279: Include library source code in distribution -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => worksforme Comment: Thanks for the suggestion. Happily, the docs already include the source code, e.g.: http://www.haskell.org/ghc/docs/latest/html/libraries/base/src /Control-Concurrent.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 15 04:46:22 2008 From: trac at galois.com (GHC) Date: Thu May 15 04:40:04 2008 Subject: [GHC] #2284: Stack-hack optimization causes much re-computation in GUI callbacks In-Reply-To: <048.962fc54d8c39b16cf1f38c360fbbf18e@localhost> References: <048.962fc54d8c39b16cf1f38c360fbbf18e@localhost> Message-ID: <057.9ca0c2f30224355cc1ae8b596c109571@localhost> #2284: Stack-hack optimization causes much re-computation in GUI callbacks -----------------------+---------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | -----------------------+---------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: And see this thread too http://www.haskell.org/pipermail/glasgow-haskell- users/2008-May/014723.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 15 04:46:56 2008 From: trac at galois.com (GHC) Date: Thu May 15 04:40:36 2008 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@localhost> References: <047.1e9bce153303809272446b6c0aede02d@localhost> Message-ID: <056.41462e8028df18ee62425663180c0b91@localhost> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+-------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: nofib/spectral/calendar | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by simonpj): See also #2284 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 15 04:59:11 2008 From: trac at galois.com (GHC) Date: Thu May 15 04:59:13 2008 Subject: [GHC] #2257: validate hangs in configure In-Reply-To: <041.16fba6c404adcf566b7f71a6b9078150@localhost> References: <041.16fba6c404adcf566b7f71a6b9078150@localhost> Message-ID: <050.f28184e346ae0e9b59021e51db28319b@localhost> #2257: validate hangs in configure --------------------------+------------------------------------------------- Reporter: nr | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 15 05:09:14 2008 From: trac at galois.com (GHC) Date: Thu May 15 05:02:54 2008 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@localhost> References: <047.1e9bce153303809272446b6c0aede02d@localhost> Message-ID: <056.1cbc02fac53222bfcc0b9e6dc8e9b8ac@localhost> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+-------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: nofib/spectral/calendar | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by guest): * cc: kfrdbs@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 15 08:14:45 2008 From: trac at galois.com (GHC) Date: Thu May 15 08:08:27 2008 Subject: [GHC] #2286: HGL library do not compile Message-ID: <054.4215bab50789703cf266b7917f1289de@localhost> #2286: HGL library do not compile --------------------------------+------------------------------------------- Reporter: rgarciapariente | Owner: Type: bug | Status: new Priority: normal | Component: libraries/HGL Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- if you try to compile HGL-3.2.0.0 in ghc 6.8.2 on Windows: C:\ghc\HGL-3.2.0.0>runghc Setup.hs configure Configuring HGL-3.2.0.0... C:\ghc\HGL-3.2.0.0>runghc Setup.hs build Preprocessing library HGL-3.2.0.0... Building HGL-3.2.0.0... Graphics/HGL/Key.hs:57:7: Could not find module `Graphics.Win32': it is a member of package Win32-2.1.1.0, which is hidden But: C:\ghc\HGL-3.2.0.0>ghc-pkg list C:/ghc/ghc-6.8.2\package.conf: Cabal-1.2.3.0, GLUT-2.1.1.1, HUnit-1.2.0.0, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, '''Win32-2.1.1.0''', array-0.1.0.0, base-3.0.1.0, bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.1, directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.2), haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, xhtml-3000.0.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 15 11:03:54 2008 From: trac at galois.com (GHC) Date: Thu May 15 10:57:33 2008 Subject: [GHC] #2287: GHCi fails to start Message-ID: <047.5d53287697af066a4caf4c1cc60cb430@localhost> #2287: GHCi fails to start -------------------------+-------------------------------------------------- Reporter: felixmar | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.9 | Severity: critical Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- GHCi fails to start with following error message: : Unknown PEi386 section name `.reloc' (while processing: C:\ghc\ghc-head \ghc-prim-0.1\HSghc-prim-0.1.o) Loading package ghc-prim ... : panic! (the 'impossible' happened) (GHC version 6.9.20080514 for i386-unknown-mingw32): loadObj: failed Both GHC version 6.9.20080514 with build setting "quick" and build setting "quickest" have this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 15 11:08:14 2008 From: trac at galois.com (GHC) Date: Thu May 15 11:01:54 2008 Subject: [GHC] #2287: GHCi fails to start In-Reply-To: <047.5d53287697af066a4caf4c1cc60cb430@localhost> References: <047.5d53287697af066a4caf4c1cc60cb430@localhost> Message-ID: <056.297869c3dbaf9a2cff0bf8b263b4b3da@localhost> #2287: GHCi fails to start -------------------------+-------------------------------------------------- Reporter: felixmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: critical | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Changes (by felixmar): * cc: fmartini@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 15 13:54:05 2008 From: trac at galois.com (GHC) Date: Thu May 15 13:47:44 2008 Subject: [GHC] #2288: ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-apple-darwin): linkBCO: >= 64k insns in BCO Message-ID: <047.0f2d4a193298d54beaf3ee3b0fbc8f50@localhost> #2288: ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386 -apple-darwin): linkBCO: >= 64k insns in BCO -------------------------+-------------------------------------------------- Reporter: mthompso | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: trivial Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- I am filing this because ghc-6.8.2 told me to; I'm not competent to distinguish bugs from my beginner's errors. I had entered sum [2, ....] where the .... were the primes up to about 80,000. I had calculated these separately and pasted the bracketed expression into the mac Terminal after the word sum. The corresponding 'module' with the one definition ( " e = sum [2,...etc...] " compiled with a brief hesitation and of course ran more or less instantly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 16 05:03:19 2008 From: trac at galois.com (GHC) Date: Fri May 16 04:56:55 2008 Subject: [GHC] #2273: inlining defeats seq In-Reply-To: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> References: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> Message-ID: <053.21280269b480dc4d467bbe6513e81e43@localhost> #2273: inlining defeats seq ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => igloo * type: bug => merge Comment: Fixed by {{{ Fri May 16 09:51:49 GMT Daylight Time 2008 simonpj@microsoft.com * Improve the treatment of 'seq' (Trac #2273) Trac #2273 showed a case in which 'seq' didn't cure the space leak it was supposed to. This patch does two things to help a) It removes a now-redundant special case in Simplify, which switched off the case-binder-swap in the early stages. This isn't necessary any more because FloatOut has improved since the Simplify code was written. And switching off the binder-swap is harmful for seq. However fix (a) is a bit fragile, so I did (b) too: b) Desugar 'seq' specially. See Note [Desugaring seq (2)] in DsUtils This isn't very robust either, since it's defeated by abstraction, but that's not something GHC can fix; the programmer should use a let! instead. M ./compiler/basicTypes/MkId.lhs -6 +14 M ./compiler/deSugar/DsUtils.lhs -9 +44 M ./compiler/simplCore/Simplify.lhs -12 +15 }}} Most of the new lines are comments! I believe this could usefully be moved to the branch too. I wonder if it'd be worth a test in `eyeball`? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 16 07:26:44 2008 From: trac at galois.com (GHC) Date: Fri May 16 07:20:22 2008 Subject: [GHC] #2014: getLinkDeps panic In-Reply-To: <043.959b8170a1a6ec2b7cea0d1cfc8fd3ff@localhost> References: <043.959b8170a1a6ec2b7cea0d1cfc8fd3ff@localhost> Message-ID: <052.9d2d67f9be1f922aa543445d1f8b7372@localhost> #2014: getLinkDeps panic ----------------------+----------------------------------------------------- Reporter: fons | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: To merge: {{{ Thu May 15 06:45:15 PDT 2008 Simon Marlow * FIX #2014: Template Haskell w/ mutually recursive modules }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 16 09:08:06 2008 From: trac at galois.com (GHC) Date: Fri May 16 09:08:05 2008 Subject: [GHC] #2257: validate hangs in configure In-Reply-To: <041.16fba6c404adcf566b7f71a6b9078150@localhost> References: <041.16fba6c404adcf566b7f71a6b9078150@localhost> Message-ID: <050.e448b630427a57d2b0956e1470c4009d@localhost> #2257: validate hangs in configure --------------------------+------------------------------------------------- Reporter: nr | Owner: igloo Type: merge | Status: new Priority: highest | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: To merge: {{{ Fri May 16 14:00:45 BST 2008 Simon Marlow * FIX #2257: timer_settime() hangs during configure }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 16 17:23:10 2008 From: trac at galois.com (GHC) Date: Fri May 16 17:16:50 2008 Subject: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!! In-Reply-To: <057.ee3a70497de9cc3d83abf1aab5293225@localhost> References: <057.ee3a70497de9cc3d83abf1aab5293225@localhost> Message-ID: <066.dd4068a2dfa313dbaa77fac4db109165@localhost> #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!! -------------------------------------------------+-------------------------- Reporter: jvlask@hotmail.com | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.6 Severity: critical | Resolution: fixed Keywords: ghci foreign ffi dll import stdcall | Difficulty: Moderate (1 day) Testcase: | Architecture: x86 Os: Windows | -------------------------------------------------+-------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 16 17:24:00 2008 From: trac at galois.com (GHC) Date: Fri May 16 17:17:37 2008 Subject: [GHC] #2234: Profiled binaries create empty files In-Reply-To: <044.7102554d75e5a8588c921a04c46a11b1@localhost> References: <044.7102554d75e5a8588c921a04c46a11b1@localhost> Message-ID: <053.e4bb119def9a6c9b97869c294218030e@localhost> #2234: Profiled binaries create empty files ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: low | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 16 17:25:15 2008 From: trac at galois.com (GHC) Date: Fri May 16 17:19:02 2008 Subject: [GHC] #1861: Uncompilable code generated In-Reply-To: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> References: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> Message-ID: <053.5db9589c8144e0d6dc476bb2d40829df@localhost> #1861: Uncompilable code generated ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 16 17:26:38 2008 From: trac at galois.com (GHC) Date: Fri May 16 17:20:14 2008 Subject: [GHC] #2072: freebsd/amd64: don't know how to mangle assembly language In-Reply-To: <046.3e104ec5c02d771b814fafeb449f23f1@localhost> References: <046.3e104ec5c02d771b814fafeb449f23f1@localhost> Message-ID: <055.53957d7c5375f77a23668824d9c1c881@localhost> #2072: freebsd/amd64: don't know how to mangle assembly language ----------------------+----------------------------------------------------- Reporter: newsham | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: ghc-asm | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 16 17:28:34 2008 From: trac at galois.com (GHC) Date: Fri May 16 17:22:11 2008 Subject: [GHC] #2228: runghc screws up terminal buffering mode and doesn't reset it In-Reply-To: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> References: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> Message-ID: <053.2fe819ac56d529dbd26620e3c6bc29cb@localhost> #2228: runghc screws up terminal buffering mode and doesn't reset it --------------------+------------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 16 17:30:51 2008 From: trac at galois.com (GHC) Date: Fri May 16 17:24:31 2008 Subject: [GHC] #1641: Binders generated by instance deriving are affected by -auto-all In-Reply-To: <045.bc1ef364192e47328bae6a907ad26026@localhost> References: <045.bc1ef364192e47328bae6a907ad26026@localhost> Message-ID: <054.3fc77caaf113a9a72757898003c893b5@localhost> #1641: Binders generated by instance deriving are affected by -auto-all ----------------------+----------------------------------------------------- Reporter: sorear | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 16 17:32:48 2008 From: trac at galois.com (GHC) Date: Fri May 16 17:26:23 2008 Subject: [GHC] #1657: throwTo + unsafeInterleaveIO oddness In-Reply-To: <044.21440a48538e444ebfd4d18aeba61e97@localhost> References: <044.21440a48538e444ebfd4d18aeba61e97@localhost> Message-ID: <053.b1510e893e9f8256ecef4f77f5d5d760@localhost> #1657: throwTo + unsafeInterleaveIO oddness ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Comment (by igloo): This should have been fixed by: {{{ Wed May 14 19:18:10 PDT 2008 Ian Lynagh * Tag the pointer in the FUN_STATIC case of evacuate Fixes trac #1657. 6.8 branch only as Simon Marlow says he will fix it differently in the HEAD as part of his GC changes. }}} but I want to confirm that it really works on Windows. Then this bug needs to be moved to the 6.10 branch, just to make sure we don't forget about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 16 17:39:06 2008 From: trac at galois.com (GHC) Date: Fri May 16 17:32:41 2008 Subject: [GHC] #2276: foreign import stdcall "&foo" doesn't work In-Reply-To: <047.799717800ba2c37716201ce0aa31af44@localhost> References: <047.799717800ba2c37716201ce0aa31af44@localhost> Message-ID: <056.b4804073b55e0f9e60e72f59a3e6806e@localhost> #2276: foreign import stdcall "&foo" doesn't work ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged (with the PprC and CLabel bits omitted) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 16 17:44:14 2008 From: trac at galois.com (GHC) Date: Fri May 16 17:37:49 2008 Subject: [GHC] #2059: Erroneous results in trigonometric functions for > double-precision values In-Reply-To: <056.3e619538850693ad9b65e875780ac3cb@localhost> References: <056.3e619538850693ad9b65e875780ac3cb@localhost> Message-ID: <065.6963d8822993ae8d9641d722f6c45db1@localhost> #2059: Erroneous results in trigonometric functions for > double-precision values -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: num009 | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * testcase: => num009 * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.8: {{{ Fri May 2 17:08:41 PDT 2008 Ian Lynagh * Fix sin/cos/tan on x86; trac #2059 If the value is > 2^63 then we need to work out its value mod 2pi, and apply the operation to that instead. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 16 20:58:47 2008 From: trac at galois.com (GHC) Date: Fri May 16 20:52:27 2008 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop Message-ID: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> #2289: Needless reboxing of values when returning from a tight loop -------------------------------------------+-------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: boxing, loops, performance | Testcase: Architecture: Unknown | Os: Unknown -------------------------------------------+-------------------------------- GHC wants to box up strict values when returning from tight inner loops, even when they're immediately taken apart. This leads to redundant instructions in the bodies of tight loops, and more code. It affects, in particular, loops that result from fusion, which need to be tight, but often return multiple values via unlifted pairs. Consider this program: {{{ {-# OPTIONS -fexcess-precision #-} {-# LANGUAGE TypeOperators #-} import System.Environment import Text.Printf import Data.Array.Vector mean :: UArr Double -> Double mean arr = s / fromIntegral l where s :*: l = foldlU k (0 :*: 0) arr :: (Double :*: Int) k (s :*: n) x = s+x :*: n+1 main = do [d] <- map read `fmap` getArgs printf "%f\n" (mean (enumFromToFracU 1 d)) }}} It generates this rather good Core (ghc 6.8.2): {{{ $s$wfold_s1rB :: Double# -> Int# -> Double# -> (# Double, Int #) $s$wfold_s1rB = \ (sc_s1rr :: Double#) (sc1_s1rs :: Int#) (sc2_s1rt :: Double#) -> case >## sc_s1rr y_a1pr of wild4_X1no { False -> $s$wfold_s1rB (+## sc_s1rr 1.0) (+# sc1_s1rs 1) (+## sc2_s1rt sc_s1rr); True -> (# D# sc2_s1rt, I# sc1_s1rs #) }; } in case $s$wfold_s1rB 2.0 1 1.0 of ww_s1qg { (# ww1_s1qi, ww2_s1qj #) -> case ww1_s1qi of wild4_a1mC { D# x_a1mE -> case ww2_s1qj of wild5_aP6 { I# x1_aP8 -> case /## x_a1mE (int2Double# x1_aP8) of wild21_a1mK { __DEFAULT -> D# wild21_a1mK }}} But note, what's this? {{{ True -> (# D# sc2_s1rt, I# sc1_s1rs #) }; } in case $s$wfold_s1rB 2.0 1 1.0 of ww_s1qg { (# ww1_s1qi, ww2_s1qj #) -> case ww1_s1qi of wild4_a1mC { D# x_a1mE -> case ww2_s1qj of wild5_aP6 { I# x1_aP8 -> case /## x_a1mE (int2Double# x1_aP8) }}} The return values of what was a strict pair are boxed, placed in an unboxed tuple, and then immediately unboxed and the division takes place. Ok, let's isolate this. Here, the boxed return, from the inner loop: {{{ mean_s19V :: Double# -> Int# -> Double# -> (# Double, Int #) mean_s19V = \ (ds1_dD3 :: Double#) (ds2_dD4 :: Int#) (ds3_dD5 :: Double#) -> case >## ds1_dD3 d#_aoG of wild4_Xw { False -> mean_s19V (+## ds1_dD3 1.0) (+# ds2_dD4 1) (+## ds3_dD5 ds1_dD3); True -> (# D# ds3_dD5, I# ds2_dD4 #) }; } in case mean_s19V 2.0 1 1.0 of wild4_Xr { (# ds1_dCV, ds2_dCW #) -> case ds1_dCV of wild5_Xv { D# x_aoR -> case ds2_dCW of wild6_Xy { I# y_aoS -> case /## x_aoR (int2Double# y_aoS) of wild7_XB { __DEFAULT -> D# wild7_XB }}} And the inner loop and exit: {{{ s1bd_info: -- what's this stuff? leaq 32(%r12), %rax cmpq %r15, %rax movq %rax, %r12 ja .L17 -- ok, to business: ucomisd 5(%rbx), %xmm5 ja .L19 movapd %xmm6, %xmm0 leaq -32(%rax), %r12 incq %rsi addsd %xmm5, %xmm0 addsd .LC1(%rip), %xmm5 movapd %xmm0, %xmm6 jmp s1bd_info .L19: movq %rsi, -16(%rax) movq $base_GHCziBase_Izh_con_info, -24(%rax) movq $base_GHCziFloat_Dzh_con_info, -8(%rax) movsd %xmm6, (%rax) leaq -7(%rax), %rbx leaq -23(%rax), %rsi jmp *(%rbp) }}} Now, I can avoid the reboxing manually: {{{ mean_s19R :: Double# -> Int# -> Double# -> (# Double#, Int# #) mean_s19R = \ (ds1_dCZ :: Double#) (ds2_dD0 :: Int#) (ds3_dD1 :: Double#) -> case >## ds1_dCZ d#_aoG of wild4_Xw { False -> mean_s19R (+## ds1_dCZ 1.0) (+# ds2_dD0 1) (+## ds3_dD1 ds1_dCZ); True -> (# ds3_dD1, ds2_dD0 #) }; } in case mean_s19R 2.0 1 1.0 of wild4_Xr { (# x_aoR, y_aoS #) -> case /## x_aoR (int2Double# y_aoS) of wild5_Xv { __DEFAULT -> D# wild5_Xv }}} And we get: {{{ s1b9_info: -- hey , our junk is gone! ucomisd 5(%rbx), %xmm5 ja .L17 movapd %xmm6, %xmm0 incq %rsi addsd %xmm5, %xmm0 addsd .LC1(%rip), %xmm5 movapd %xmm0, %xmm6 jmp s1b9_info -- cool, that was it, let's go home: .L17: movapd %xmm6, %xmm5 movq %rsi, %rbx jmp *(%rbp) }}} Which is a much better result. The loop is tighter. What can be done here? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 17 01:42:20 2008 From: trac at galois.com (GHC) Date: Sat May 17 01:35:59 2008 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> Message-ID: <052.9edb99b407aa46679a4d550efc30ace7@localhost> #2289: Needless reboxing of values when returning from a tight loop -------------------------------------------+-------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: boxing, loops, performance | Testcase: Architecture: Unknown | Os: Unknown -------------------------------------------+-------------------------------- Comment (by dons): Here's a simple test case: {{{ {-# LANGUAGE TypeOperators #-} {-# OPTIONS -funbox-strict-fields #-} import System.Environment import Text.Printf data P a b = P !a !b mean :: Double -> Double -> P Double Int mean n m = go n 0 0 where go :: Double -> Int -> Double -> P Double Int go x l s | x > m = P s l | otherwise = go (x+1) (l+1) (s+x) main = do [d] <- map read `fmap` getArgs printf "%f\n" (case mean 1 d of (P x y) -> x / fromIntegral y ) }}} Yields: {{{ $wgo_s1az :: Double# -> Int# -> Double# -> (# Double, Int #) $wgo_s1az = \ (ww_X1au :: Double#) (ww1_X1az :: Int#) (ww2_X1aE :: Double#) -> case >## ww_X1au y_a178 of wild4_X1g { False -> $wgo_s1az (+## ww_X1au 1.0) (+# ww1_X1az 1) (+## ww2_X1aE ww_X1au); True -> (# D# ww2_X1aE, I# ww1_X1az #) }; } in case $wgo_s1az 2.0 1 1.0 of ww_s1a2 { (# ww1_s1a4, ww2_s1a5 #) -> case ww1_s1a4 of wild4_a17r { D# x_a17t -> case ww2_s1a5 of wild5_aEV { I# x1_aEX -> case /## x_a17t (int2Double# x1_aEX) of wild21_a17z { __DEFAULT -> D# wild21_a17z }}} Exhibiting the reboxing. Running this: {{{ $ time ./G 1e9 500000000.067109 ./G 1e9 2.21s user 0.00s system 99% cpu 2.225 total }}} While if we prevent the reboxing, by moving the division inside the loop: {{{ $wgo_s1a0 :: Double# -> Int# -> Double# -> Double# $wgo_s1a0 = \ (ww_X19X :: Double#) (ww1_X1a2 :: Int#) (ww2_X1a7 :: Double#) -> case >## ww_X19X y_a16C of wild4_X1g { False -> $wgo_s1a0 (+## ww_X19X 1.0) (+# ww1_X1a2 1) (+## ww2_X1a7 ww_X19X); True -> /## ww2_X1a7 (int2Double# ww1_X1a2 }}} We get faster code: {{{ $ time ./G 1e9 500000000.067109 ./G 1e9 1.84s user 0.01s system 99% cpu 1.861 total }}} So I suspect the boxing causes a heap check to end up inside the loop (run on every iteration?), and thus a performance loss. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 17 11:24:37 2008 From: trac at galois.com (GHC) Date: Sat May 17 11:18:20 2008 Subject: [GHC] #2246: Numeric literal very badly optimized In-Reply-To: <044.ea64e9326ad25932314b8864281b1a7d@localhost> References: <044.ea64e9326ad25932314b8864281b1a7d@localhost> Message-ID: <053.d36e34b97fc933157699387a759cbf43@localhost> #2246: Numeric literal very badly optimized ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: It doesn't merge cleanly, so I've skipped it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 17 11:25:21 2008 From: trac at galois.com (GHC) Date: Sat May 17 11:18:54 2008 Subject: [GHC] #2290: Impossible happens compiling darcs Message-ID: <049.ea217d551b09985946e64848df26b80d@localhost> #2290: Impossible happens compiling darcs ----------------------------------+----------------------------------------- Reporter: tux_rocker | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: impossible, linux | Testcase: Architecture: x86 | Os: Linux ----------------------------------+----------------------------------------- When I compile darcs with profiling (doing "./configure --disable-threaded --enable-profiling"), I get: {{{ rm -f Main.hi Main.o [ghc] stringify PATH=".:$PATH" darcs changes --context | cat config.command - \ | ./stringify Context context > \src/Context.hs darcs failed: Not a repository Rebuild dependencies ... [ghc] src/ThisVersion.o [ghc] src/Autoconf.o [ghc] src/Context.o [ghc] src/Workaround.o [ghc] src/CommandLine.o [ghc] src/FastPackedString.o [ghc] src/Printer.o [ghc] src/Darcs/Global.o [ghc] src/HTTP.o [ghc] src/Darcs/Bug.o [ghc] src/Darcs/SignalHandler.o [ghc] src/Darcs/Show.o [ghc] src/Darcs/Sealed.o [ghc] src/Darcs/Patch/Ordered.o [ghc] src/Darcs/Progress.o [ghc] src/Exec.o [ghc] src/Darcs/Utils.o [ghc] src/Darcs/Compat.o [ghc] src/UTF8.o [ghc] src/FileName.o [ghc] src/Darcs/URL.o [ghc] src/Darcs/Lock.o [ghc] src/URL.o [ghc] src/IsoDate.o [ghc] src/DateMatcher.o [ghc] src/English.o [ghc] src/FileSystem.o [ghc] src/Lcs.o [ghc] src/OldDate.o [ghc] src/OldFastPackedString.o [ghc] src/RegChars.o [ghc] src/SHA1.o ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): RegAllocLinear.getStackSlotFor: out of stack slots }}} {{{uname -a}}} tells me: {{{Linux curry 2.6.24-gentoo-r2 #5 SMP Sat Feb 16 12:34:01 CET 2008 i686 Genuine Intel(R) CPU 1400 @ 1.83GHz GenuineIntel GNU/Linux}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 17 11:29:11 2008 From: trac at galois.com (GHC) Date: Sat May 17 11:22:47 2008 Subject: [GHC] #2277: GHCi silently aborts on 'take' computation In-Reply-To: <046.02df5e44a831fb20777998dee9adae29@localhost> References: <046.02df5e44a831fb20777998dee9adae29@localhost> Message-ID: <055.231c5e2352ad6982784162bc7bc72d32@localhost> #2277: GHCi silently aborts on 'take' computation ---------------------+------------------------------------------------------ Reporter: cdsmith | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Comment (by igloo): Aha, I can reproduce it intermittently. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 17 13:58:02 2008 From: trac at galois.com (GHC) Date: Sat May 17 13:51:35 2008 Subject: [GHC] #2277: GHCi silently aborts on 'take' computation In-Reply-To: <046.02df5e44a831fb20777998dee9adae29@localhost> References: <046.02df5e44a831fb20777998dee9adae29@localhost> Message-ID: <055.74401a9e12726860d1cc72f66ce60011@localhost> #2277: GHCi silently aborts on 'take' computation ---------------------+------------------------------------------------------ Reporter: cdsmith | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Comment (by igloo): OK, so this comes down to {{{ if (tcsetattr(el->el_infd, TCSADRAIN, &el->el_tty.t_ed) == -1) { }}} getting an Interrupted system call, presumably due to our timer. I'm not sure what the solution to this is. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 17 15:09:00 2008 From: trac at galois.com (GHC) Date: Sat May 17 15:02:34 2008 Subject: [GHC] #2014: getLinkDeps panic In-Reply-To: <043.959b8170a1a6ec2b7cea0d1cfc8fd3ff@localhost> References: <043.959b8170a1a6ec2b7cea0d1cfc8fd3ff@localhost> Message-ID: <052.0aacc0c9a117740ef98522bdedbffac7@localhost> #2014: getLinkDeps panic ----------------------+----------------------------------------------------- Reporter: fons | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 17 15:07:30 2008 From: trac at galois.com (GHC) Date: Sat May 17 15:07:25 2008 Subject: [GHC] #2257: validate hangs in configure In-Reply-To: <041.16fba6c404adcf566b7f71a6b9078150@localhost> References: <041.16fba6c404adcf566b7f71a6b9078150@localhost> Message-ID: <050.f9b68cb2bb3d39eb4f11ca77a8fe583f@localhost> #2257: validate hangs in configure --------------------------+------------------------------------------------- Reporter: nr | Owner: igloo Type: merge | Status: closed Priority: highest | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 17 15:22:55 2008 From: trac at galois.com (GHC) Date: Sat May 17 15:16:27 2008 Subject: [GHC] #2264: Validate using ghc-6.4.1: 3 failures, 1 workaround, 1 fix In-Reply-To: <050.9517ae6a8909fd14ebd0a610f101a565@localhost> References: <050.9517ae6a8909fd14ebd0a610f101a565@localhost> Message-ID: <059.1124c1ca70a91ff105ea44d9e89bc55f@localhost> #2264: Validate using ghc-6.4.1: 3 failures, 1 workaround, 1 fix -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Ah, OK. I was thrown by the {{{ GHC internal error: `a' is not in scope }}} errors. Anyhow, GHC now validates with 6.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 17 17:06:21 2008 From: trac at galois.com (GHC) Date: Sat May 17 16:59:57 2008 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> Message-ID: <052.b1a4344fe58b2dc2bf6570cf5221ddbf@localhost> #2289: Needless reboxing of values when returning from a tight loop -------------------------------------------+-------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: boxing, loops, performance | Testcase: Architecture: Unknown | Os: Unknown -------------------------------------------+-------------------------------- Comment (by dons): Note that if we specialise the constructor manually, we can get the correct unboxing: That is, just using strict pairs isn't enough: {{{ data P a b = P {-# UNPACK #-} !a {-# UNPACK #-} !b }}} won't work. where we use P only for P Double Int, I'm unable to get the return value unboxed. If we specialise P, data P = P !Double !Int, then we do get the unpacking, as expected. This makes strict pairs a little less useful for accumulating state -- we have to specialise them directly ourselves to avoid the reboxing penalty. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 17 17:39:14 2008 From: trac at galois.com (GHC) Date: Sat May 17 17:32:46 2008 Subject: [GHC] #2291: Panic mixing RULES and Type Families Message-ID: <044.b4e939c7ecb85225e2cb80cd7a7bcd20@localhost> #2291: Panic mixing RULES and Type Families ---------------------------------------------+------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: type families, rewrite rules | Testcase: attached Architecture: Multiple | Os: Linux ---------------------------------------------+------------------------------ It appears that RULES pragmas and type families don't always play nice. When either of the last two RULES is present, you get an error analogous to the following. Attempting to supply a manual type annotation did not help. Attached is a simplified test case. [1 of 1] Compiling Small ( Small.hs, interpreted ) ghc-6.9.20080401: panic! (the 'impossible' happened) (GHC version 6.9.20080401 for i386-unknown-linux): tcSimplifyRuleLhs Wanted t_apn{tv} [tau] :: main:Small.Coexp{tc roa} k{tv apj} [tau] b{tv apm} [tau] c{tv apk} [tau] ~ main:Small.Coexp{tc roa} k{tv apj} [tau] b{tv apb} [tau] c{tv apc} [tau] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 17 21:04:28 2008 From: trac at galois.com (GHC) Date: Sat May 17 20:58:02 2008 Subject: [GHC] #1657: throwTo + unsafeInterleaveIO oddness In-Reply-To: <044.21440a48538e444ebfd4d18aeba61e97@localhost> References: <044.21440a48538e444ebfd4d18aeba61e97@localhost> Message-ID: <053.e6cdaec1907366f7e0d8b9d2302d4a5d@localhost> #1657: throwTo + unsafeInterleaveIO oddness ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Comment (by igloo): Looks like this still isn't completely fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 18 05:28:26 2008 From: trac at galois.com (GHC) Date: Sun May 18 05:21:58 2008 Subject: [GHC] #2292: Poor error message if type signature lacks definition Message-ID: <051.036bd49704eab0601f4378d15f12016d@localhost> #2292: Poor error message if type signature lacks definition -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- The file {{{ nub :: a }}} Produces the error message in GHC: {{{ Temp.hs:5:0: Not in scope: `nub' }}} The problem isn't that {{{nub}}} is not in scope, but that there is no definition. Importing {{{Data.List}}} (and bringing {{{nub}}} into scope) doesn't solve the problem, but gives a new error message. Hugs does quite a bit better: {{{ ERROR file:.\Temp.hs:5 - Missing binding for variable "nub" in type signature }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 18 07:27:36 2008 From: trac at galois.com (GHC) Date: Sun May 18 07:21:07 2008 Subject: [GHC] #2293: Multiple declaration error shown multiple times Message-ID: <051.ed7e1c8300f38a10ee6d2df1bb501c8b@localhost> #2293: Multiple declaration error shown multiple times -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Given the file: {{{ foo = 1 a = () foo = 1 b = () foo = 1 }}} You get the error message: {{{ Uniplate.hs:3:0: Multiple declarations of `Main.foo' Declared at: Uniplate.hs:1:0 Uniplate.hs:3:0 Uniplate.hs:5:0: Multiple declarations of `Main.foo' Declared at: Uniplate.hs:1:0 Uniplate.hs:5:0 }}} Instead of the much simpler: {{{ Uniplate.hs:5:0: Multiple declarations of `Main.foo' Declared at: Uniplate.hs:1:0 Uniplate.hs:3:0 Uniplate.hs:5:0 }}} This also happens with multiple class definitions, but if you give multiple type signatures then the error message is properly merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 18 12:40:09 2008 From: trac at galois.com (GHC) Date: Sun May 18 12:33:42 2008 Subject: [GHC] #789: BCOs can only have 64k instructions In-Reply-To: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> References: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> Message-ID: <055.327494d83dd7efeb44b446fb8133721d@localhost> #789: BCOs can only have 64k instructions ---------------------+------------------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: BCO | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------+------------------------------------------------------ Comment (by bboissin): testbco.hs makes the panic triggers with GHC version 6.8.2 for i386 -unknown-linux. It is a regression since it was working fine with previous versions (I believe GHC 6.6 from ubuntu gutsy and feisty). what I was doing is probably dumb but it was working fine for me :) (I was learning haskell playing with project euler and wasn't yet into monads, so the fastest way for me was to put the data with the code instead of loading a file). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 18 12:43:42 2008 From: trac at galois.com (GHC) Date: Sun May 18 12:37:11 2008 Subject: [GHC] #2288: ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-apple-darwin): linkBCO: >= 64k insns in BCO In-Reply-To: <047.0f2d4a193298d54beaf3ee3b0fbc8f50@localhost> References: <047.0f2d4a193298d54beaf3ee3b0fbc8f50@localhost> Message-ID: <056.71c1c77e86d9973f03dcb16ddfe13d4b@localhost> #2288: ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386 -apple-darwin): linkBCO: >= 64k insns in BCO -------------------------+-------------------------------------------------- Reporter: mthompso | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: duplicate Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Changes (by bboissin): * status: new => closed * resolution: => duplicate Comment: dup of #789 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 18 15:19:38 2008 From: trac at galois.com (GHC) Date: Sun May 18 15:13:11 2008 Subject: [GHC] #2294: Misleading error message suggestion Message-ID: <051.499e79c0338174afbcd455d41d580a43@localhost> #2294: Misleading error message suggestion -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Given a rank-2 type, such as: {{{ id :: forall a . a -> a id x = x }}} The compiler complains: {{{ Uniplate.hs:3:15: Illegal operator `.' in type `forall a . (a -> a)' (Use -XTypeOperators to allow operators in types) }}} Of course, people using {{{`.'}}} in a type signature are much more likely to be aiming for {{{Rank2Types}}} - so perhaps in this one type operator the suggestion should be towards rank-2 types. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 18 15:39:12 2008 From: trac at galois.com (GHC) Date: Sun May 18 15:32:42 2008 Subject: [GHC] #1963: Pressing ^C at the right moment can trash GHC's package list In-Reply-To: <044.fe68034f1a304106efaa8e4a323fded8@localhost> References: <044.fe68034f1a304106efaa8e4a323fded8@localhost> Message-ID: <053.add14ab8170d15fb9962686968a6ac25@localhost> #1963: Pressing ^C at the right moment can trash GHC's package list ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by duncan): Instead of the dodgy backing up of the old file, it should use the `writeFileAtomic` from Cabal. On Unix it is genuinely atomic (assuming ^C is turned into an exception) and on Windows there is a very narrow race condition but it's probably a good deal narrower than in `ghc-pkg`'s current impl. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 19 05:43:03 2008 From: trac at galois.com (GHC) Date: Mon May 19 05:36:43 2008 Subject: [GHC] #2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid argument (Invalid argument)" In-Reply-To: <045.9f2f177f681138fbf7d90d1273238fd5@localhost> References: <045.9f2f177f681138fbf7d90d1273238fd5@localhost> Message-ID: <054.7201a4976562aa7d94562abf1880ebe8@localhost> #2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid argument (Invalid argument)" -----------------------------------+---------------------------------------- Reporter: slyfox | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: libraries/unix | Version: 6.8.2 Severity: major | Resolution: Keywords: regression, ffi, unix | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -----------------------------------+---------------------------------------- Changes (by Eelis-): * cc: hackage.haskell.org@contacts.eelis.net (added) Comment: As requested in the [http://www.haskell.org/pipermail/glasgow-haskell- users/2008-March/014467.html Release Plans] message, I'm hereby expressing that this bug is very important to me. It pretty much makes [http://www.eelis.net/geordi/ geordi] completely unusable on x86-32. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 19 06:06:44 2008 From: trac at galois.com (GHC) Date: Mon May 19 06:00:12 2008 Subject: [GHC] #2002: problems with very large (list) literals In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> Message-ID: <060.aa3ebfb1946f0fbb0ae1a2a1ab661d1b@localhost> #2002: problems with very large (list) literals ------------------------------------------+--------------------------------- Reporter: Isaac Dupree | Owner: simonmar Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 19 06:19:39 2008 From: trac at galois.com (GHC) Date: Mon May 19 06:13:08 2008 Subject: [GHC] #2164: zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd In-Reply-To: <044.65631559df6ce2cd79a1eb038ea82f5f@localhost> References: <044.65631559df6ce2cd79a1eb038ea82f5f@localhost> Message-ID: <053.e4019aed508ad20a2edc34acda925183@localhost> #2164: zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd ----------------------------+----------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler (FFI) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 19 07:01:33 2008 From: trac at galois.com (GHC) Date: Mon May 19 06:55:03 2008 Subject: [GHC] #2295: Combined -odir/-hidir flag Message-ID: <051.3ec75d5010176a8f7458111511793c49@localhost> #2295: Combined -odir/-hidir flag --------------------------------+------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Component: Driver Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Many of my command line invocations are: {{{ ghc -odir obj -hidir obj ... }}} I nearly always set both {{{-odir}}} and {{{-hidir}}} to the same thing, typically to just ask for the temporary files to not crowd the code files. It would be useful if there was one combined flag, perhaps {{{-tdir}}} (temporary), which gave default values to both {{{-odir}}} and {{{-hidir}}}. Another option (suggested by quicksilver) is that {{{-hidir}}} could default to {{{-odir}}} unless set explicitly - since .hi files are really just compiler details, as far as the user is concerned. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 19 07:30:17 2008 From: trac at galois.com (GHC) Date: Mon May 19 07:23:45 2008 Subject: [GHC] #2002: problems with very large (list) literals In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> Message-ID: <060.f7c7e3992acdec86592672c5d00a540b@localhost> #2002: problems with very large (list) literals ------------------------------------------+--------------------------------- Reporter: Isaac Dupree | Owner: simonmar Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Changes (by guest): * cc: kfrdbs@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 19 07:42:29 2008 From: trac at galois.com (GHC) Date: Mon May 19 07:35:57 2008 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> Message-ID: <052.825efebd19c28d17becd3582bde4b7c0@localhost> #2289: Needless reboxing of values when returning from a tight loop ----------------------------------------+----------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: boxing, loops, performance | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------------+----------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Nice example. I took a little look at it. Two things First, yes GHC never does a heap-check at the start of an alternative of a primop case; that is, one whose scrutinee is just a primop application. In this example that's bad, because there is no allocation before the conditional, and the hot path does no allocation at all. The fix is to put the heap check at the start of the alternatives, if no allocation precedes the case itself. This would require a significant (but not drastic) change to the code generator. Happily, it'll be a much easier change when John Dias's new back end comes on stream, we'll hold it till then. Second, and orthogonally, this loop has a nested CPR property. There is no reason that the CPR analyser can't deal with nested stuff, but it doesn't. There's a nice little project there too. Either of these would fix this particular example, but both are valuable in their own right. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 19 07:52:41 2008 From: trac at galois.com (GHC) Date: Mon May 19 07:46:09 2008 Subject: [GHC] #2295: Combined -odir/-hidir flag In-Reply-To: <051.3ec75d5010176a8f7458111511793c49@localhost> References: <051.3ec75d5010176a8f7458111511793c49@localhost> Message-ID: <060.d63350d1f416a181a1d864b29bbcfe6f@localhost> #2295: Combined -odir/-hidir flag --------------------------------+------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Comment (by duncan): Note also the `-stubdir` flag which sets the dir where `_stub.c` and `_stub.h` files get dropped. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 19 14:36:08 2008 From: trac at galois.com (GHC) Date: Mon May 19 14:29:41 2008 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> Message-ID: <052.ef3c6b87624d4d819fafea92511ef6f8@localhost> #2289: Needless reboxing of values when returning from a tight loop ----------------------------------------+----------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: boxing, loops, performance | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------------+----------------------------------- Comment (by dons): Looking in the CPR analyser, I see the following comment: The analysis here detects nested CPR information. For example, if a function returns a constructed pair, the first element of which is a constructed int, then the analysis will detect nested CPR information for the int as well. Unfortunately, the current transformations can't take advantage of the nested CPR information. They have (broken now, I think) code which will flatten out nested CPR components and rebuild them in the wrapper, but enabling this would lose laziness. It is possible to make use of the nested info: if we knew that a caller was strict in that position then we could create a specialized version of the function which flattened/reconstructed that position. It is not known whether this optimisation would be worthwhile. So, there's some skeleton code in their for the nested CPR stuff. And the CPR analyser seems pretty small too. Would working on this be worthwhile now? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 19 15:48:49 2008 From: trac at galois.com (GHC) Date: Mon May 19 15:42:16 2008 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> Message-ID: <052.ed04f0816242f78e6600b24ee99d0fb1@localhost> #2289: Needless reboxing of values when returning from a tight loop ----------------------------------------+----------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: boxing, loops, performance | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------------+----------------------------------- Comment (by simonpj): Rats. I'd forgotten about the strictness question: {{{ f :: Int -> (Int,Int) f x = (g x, h x) }} Suppose `g` and `h` have the CPR property -- that is, they explicitly return a boxed value. Then it's a mistake to transform to {{{ f x = case (g x, h x) of { (I# r1, I# r2) -> (I# r1 ,I# r2) } }}} because that'd make f too strict. But in your example, `g` and `h` are themselves constructors. My conclusion: for the ''nested'' part of CPR analysis we do not want to "look through" function calls, but rather look only for literal constructor applications. I have not thought about how much this'd affect the analysis. Provided the analysis was modified in this way, it shouldn't be too hard to modify the worker/wrapper part to take account of it. But NB that CprAnalyse is dead code; the current analysis is done as part of strictness analysis in DmdAnal. And the strictness analyser itself needs love and attention. So much to do, so little time. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 19 15:51:18 2008 From: trac at galois.com (GHC) Date: Mon May 19 15:44:44 2008 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> Message-ID: <052.d5958579fad472a91de200eefcdba383@localhost> #2289: Needless reboxing of values when returning from a tight loop ----------------------------------------+----------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: boxing, loops, performance | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------------+----------------------------------- Comment (by simonpj): (Retrying, having messed up typesetting.) Rats. I'd forgotten about the strictness question: {{{ f :: Int -> (Int,Int) f x = (g x, h x) }}} Suppose `g` and `h` have the CPR property -- that is, they explicitly return a boxed value. Then it's a mistake to transform to {{{ f x = case (g x, h x) of { (I# r1, I# r2) -> (I# r1 ,I# r2) } }}} because that'd make f too strict. But in your example, `g` and `h` are themselves constructors. My conclusion: for the ''nested'' part of CPR analysis we do not want to "look through" function calls, but rather look only for literal constructor applications. I have not thought about how much this'd affect the analysis. Provided the analysis was modified in this way, it shouldn't be too hard to modify the worker/wrapper part to take account of it. But NB that `CprAnalyse` is dead code; the current analysis is done as part of strictness analysis in `DmdAnal`. And the strictness analyser itself needs love and attention. So much to do, so little time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 19 19:41:38 2008 From: trac at galois.com (GHC) Date: Mon May 19 19:35:05 2008 Subject: [GHC] #2296: Functional dependencies error message has no position information Message-ID: <051.b7043276a2125146a84a038bd8ef8992@localhost> #2296: Functional dependencies error message has no position information -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- When compiling the attached file (sorry its really long, it could easily be reduced to a minimal test case - although I don't think its necessary to fix the bug), I get the error message: {{{ E:\Neil\thesis\obj\haskell2/Proof_default.hs:1:0: Couldn't match expected type `Expr' against inferred type `VarName' Expected type: ([Expr], [Expr]) Inferred type: ([VarName], a) When using functional dependencies to combine Subst (Prop (Sat VarName)) ([VarName], a) (Prop (Sat Expr)), arising from a use of `/' at E:\Neil\thesis\obj\haskell2/Proof_default.hs:391:17-54 Subst (Prop (Sat Expr)) ([Expr], [Expr]) (Prop (Sat Expr)), arising from a use of `/' at E:\Neil\thesis\obj\haskell2/Proof_default.hs:399:17-44 }}} The error message lists two positions further down, but gives no position (or 1:0) at the top of the message. One of the positions from further down should be given - either one would do - otherwise the user may miss that there is position information available (I did at first). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 19 19:55:55 2008 From: trac at galois.com (GHC) Date: Mon May 19 19:49:21 2008 Subject: [GHC] #2296: Functional dependencies error message has no position information In-Reply-To: <051.b7043276a2125146a84a038bd8ef8992@localhost> References: <051.b7043276a2125146a84a038bd8ef8992@localhost> Message-ID: <060.fc9e09b918a190e195307ec413345b33@localhost> #2296: Functional dependencies error message has no position information -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Comment (by NeilMitchell): I just got a very similar error message off slightly different code, which gives slightly different information: {{{ E:\Neil\thesis\obj\haskell2/Proof_default.hs:1:0: Couldn't match expected type `VarName' against inferred type `Expr' Expected type: ([VarName], [Expr]) Inferred type: ([Expr], [b]) When using functional dependencies to combine Subst (Sat a) ([a], [b]) (Sat b), arising from the instance declaration at E:\Neil\thesis\obj\haskell2/Pr of_default.hs:140:0 Subst (Sat Expr) ([VarName], [Expr]) (Sat Expr), arising from a use of `/' at E:\Neil\thesis\obj\haskell2/Proof_default.hs:402:17-43 }}} Here the relevant position is the second one (the use, not the definition), so this bug can't just be fixed by grabbing the first position out of the list. I've again attached a sample piece of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 19 21:08:33 2008 From: trac at galois.com (GHC) Date: Mon May 19 21:01:59 2008 Subject: [GHC] #2297: Profiler is inconsistent about biography for GHC's heap Message-ID: <044.fbea862bca1709c4fb82e649273727f1@localhost> #2297: Profiler is inconsistent about biography for GHC's heap --------------------------+------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Profiling | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown --------------------------+------------------------------------------------- My slightly modified `rnBind` has this clause (`i` is an `Int`): {{{ rnBind sig_fn trim i (L loc (FunBind { fun_id = name, fun_infix = inf, fun_matches = matches, -- no pattern FVs bind_fvs = _ })) -- invariant: no free vars here when it's a FunBind = i `seq` setSrcSpan loc $ do { let plain_name = unLoc name ; (matches', fvs) <- bindSigTyVarsFV (sig_fn plain_name) $ -- bindSigTyVars tests for Opt_ScopedTyVars rnMatchGroup (FunRhs plain_name inf) matches ; checkPrecMatch inf plain_name matches' ; return (L loc (trace ("Using FunBind for " ++ show i) (FunBind { fun_id = name, fun_infix = inf, fun_matches = matches', bind_fvs = trim fvs, fun_co_fn = idHsWrapper, fun_tick = Nothing })), [plain_name], fvs) } }}} If I comment out the trace and run {{{ ghc --make J -fforce-recomp +RTS -p -hcrnBind -hyHsBindLR -hb }}} then I get `notrace.png`, all VOID. However, with the trace I get `trace.png`, LAG turning into DRAG. The two graphs are also a slightly different shape, which is curious. Also attached is the core for with and without the tracing. I think the only interesting difference is {{{ - a30_ [ALWAYS Just L] :: NameSet.FreeVars + a30_ [ALWAYS Just L] :: HsBinds.HsBindLR Name.Name Name.Name [Str: DmdType] - a30_ = w1_ ww3_ } in - let { - a31_ :: HsBinds.HsWrapper - [] - a31_ = - __scc {rnBind ghc-6.9.20080517:RnBinds !} - __scc {idHsWrapper ghc-6.9.20080517:HsBinds} HsBinds.WpHole } in - let { - a32_ :: HsBinds.HsWrapper - [] - a32_ = - __scc {rnBind ghc-6.9.20080517:RnBinds !} - __scc {idHsWrapper ghc-6.9.20080517:HsBinds} HsBinds.WpHole } in - let { - a33_ :: HsBinds.HsBindLR Name.Name Name.Name - [Str: DmdType] - a33_ = - HsBinds.FunBind - @ Name.Name - @ Name.Name - name_ - inf_ - ww2_ - a32_ - a30_ - (Data.Maybe.Nothing @ (GHC.Base.Int, [Name.Name])) } in + a30_ = + Debug.Trace.trace + @ (HsBinds.HsBindLR Name.Name Name.Name) + lvl45_ + (HsBinds.FunBind + @ Name.Name + @ Name.Name + name_ + inf_ + ww2_ + (__scc {rnBind ghc-6.9.20080517:RnBinds !} + __scc {idHsWrapper ghc-6.9.20080517:HsBinds} HsBinds.WpHole) + (w1_ ww3_) + (Data.Maybe.Nothing @ (GHC.Base.Int, [Name.Name]))) } in }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 19 21:16:30 2008 From: trac at galois.com (GHC) Date: Mon May 19 21:09:55 2008 Subject: [GHC] #2297: Profiler is inconsistent about biography for GHC's heap In-Reply-To: <044.fbea862bca1709c4fb82e649273727f1@localhost> References: <044.fbea862bca1709c4fb82e649273727f1@localhost> Message-ID: <053.1ce66f4587c77f024c7745d13cc7a2c1@localhost> #2297: Profiler is inconsistent about biography for GHC's heap -----------------------+---------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Profiling | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------+---------------------------------------------------- Comment (by igloo): In case this doesn't get sorted soon, I think these are all the relevant changes I've made: {{{ hunk ./compiler/rename/RnBinds.lhs 40 -import Digraph ( SCC(..), stronglyConnComp ) +import Digraph hunk ./compiler/rename/RnBinds.lhs 45 -import Util ( filterOut ) -import Monad ( foldM, unless ) +import Util +import Monad +import Control.Exception +import Debug.Trace hunk ./compiler/rename/RnBinds.lhs 321 - binds_w_dus <- mapBagM (rnBind (mkSigTvFn sigs') trim) mbinds + xs <- zipWithM (rnBind (mkSigTvFn sigs') trim) [1..] (bagToList mbinds) + let binds_w_dus = listToBag xs hunk ./compiler/rename/RnBinds.lhs 498 + -> Int hunk ./compiler/rename/RnBinds.lhs 501 -rnBind _ trim (L loc (PatBind { pat_lhs = pat, - pat_rhs = grhss, - -- pat fvs were stored here while - -- processing the LHS - bind_fvs=pat_fvs })) +rnBind _ trim i (L loc (PatBind { pat_lhs = pat, + pat_rhs = grhss, + -- pat fvs were stored here while + -- processing the LHS + bind_fvs=pat_fvs })) hunk ./compiler/rename/RnBinds.lhs 519 - trim + trim + i hunk ./compiler/rename/RnBinds.lhs 528 - = setSrcSpan loc $ + = i `seq` setSrcSpan loc $ hunk ./compiler/rename/RnBinds.lhs 537 - ; return (L loc (FunBind { fun_id = name, + ; return + (L loc (trace ("Using FunBind for " ++ show i) + (FunBind { fun_id = name, hunk ./compiler/rename/RnBinds.lhs 544 - fun_tick = Nothing }), + fun_tick = Nothing })), hunk ./compiler/rename/RnBinds.lhs 549 -rnBind _ _ b = pprPanic "rnBind" (ppr b) +rnBind _ _ _ b = pprPanic "rnBind" (ppr b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 04:10:01 2008 From: trac at galois.com (GHC) Date: Tue May 20 04:03:29 2008 Subject: [GHC] #2290: Impossible happens compiling darcs In-Reply-To: <049.ea217d551b09985946e64848df26b80d@localhost> References: <049.ea217d551b09985946e64848df26b80d@localhost> Message-ID: <058.afa2b49b0f515216299698cd79574e5b@localhost> #2290: Impossible happens compiling darcs -------------------------------+-------------------------------------------- Reporter: tux_rocker | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: impossible, linux | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Already reported as #1993, but thanks anyway! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 04:12:13 2008 From: trac at galois.com (GHC) Date: Tue May 20 04:05:42 2008 Subject: [GHC] #2277: GHCi silently aborts on 'take' computation In-Reply-To: <046.02df5e44a831fb20777998dee9adae29@localhost> References: <046.02df5e44a831fb20777998dee9adae29@localhost> Message-ID: <055.f7ab6f9afcf37c8dae49650890d8f660@localhost> #2277: GHCi silently aborts on 'take' computation ---------------------+------------------------------------------------------ Reporter: cdsmith | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Comment (by simonmar): That tcsetattr call is from editline, I presume? If so, we should report it upstream. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 04:15:15 2008 From: trac at galois.com (GHC) Date: Tue May 20 04:08:41 2008 Subject: [GHC] #1963: Pressing ^C at the right moment can trash GHC's package list In-Reply-To: <044.fe68034f1a304106efaa8e4a323fded8@localhost> References: <044.fe68034f1a304106efaa8e4a323fded8@localhost> Message-ID: <053.a48f77c3bd10b318f114429aa1450ebd@localhost> #1963: Pressing ^C at the right moment can trash GHC's package list ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: closed => reopened * resolution: fixed => * milestone: 6.8.3 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 04:37:57 2008 From: trac at galois.com (GHC) Date: Tue May 20 04:31:23 2008 Subject: [GHC] #2294: Misleading error message suggestion In-Reply-To: <051.499e79c0338174afbcd455d41d580a43@localhost> References: <051.499e79c0338174afbcd455d41d580a43@localhost> Message-ID: <060.cb346500f51ec779d0a99d543b3de3e7@localhost> #2294: Misleading error message suggestion --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: I improved this a little while ago (HEAD only) {{{ Foo1.hs:5:15: Illegal operator `.' in type `forall a . (a -> a)' Perhaps you intended to use -XRankNTypes or similar flag }}} I think this is what you were suggesting. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 10:13:26 2008 From: trac at galois.com (GHC) Date: Tue May 20 10:06:51 2008 Subject: [GHC] #1955: Heap profiling on Windows doesn't work In-Reply-To: <051.41700a7931b75f5016d260a75d133aed@localhost> References: <051.41700a7931b75f5016d260a75d133aed@localhost> Message-ID: <060.7de45ccd38e17f64440ec1b9a3962238@localhost> #1955: Heap profiling on Windows doesn't work ----------------------------+----------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: To merge: {{{ Mon May 19 05:51:01 PDT 2008 Simon Marlow * FIX #1955: confusion between .exe.hp and .hp suffixes for heap profiles }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 11:12:36 2008 From: trac at galois.com (GHC) Date: Tue May 20 11:06:01 2008 Subject: [GHC] #2291: Panic mixing RULES and Type Families In-Reply-To: <044.b4e939c7ecb85225e2cb80cd7a7bcd20@localhost> References: <044.b4e939c7ecb85225e2cb80cd7a7bcd20@localhost> Message-ID: <053.9bf49805783283f9dda6d8811cbcfe07@localhost> #2291: Panic mixing RULES and Type Families ---------------------------------------------+------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: type families, rewrite rules | Testcase: attached Architecture: Multiple | Os: Linux ---------------------------------------------+------------------------------ Changes (by guest): * cc: ekmett@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 12:38:59 2008 From: trac at galois.com (GHC) Date: Tue May 20 12:32:23 2008 Subject: [GHC] #1963: Pressing ^C at the right moment can trash GHC's package list In-Reply-To: <044.fe68034f1a304106efaa8e4a323fded8@localhost> References: <044.fe68034f1a304106efaa8e4a323fded8@localhost> Message-ID: <053.f680261f37914841f202811d3298f1e1@localhost> #1963: Pressing ^C at the right moment can trash GHC's package list ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): `writeFileAtomic` sounds like it belongs in `base`, not `Cabal`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 14:09:09 2008 From: trac at galois.com (GHC) Date: Tue May 20 14:02:32 2008 Subject: [GHC] #2298: renameFile is not atomic on Windows Message-ID: <045.dd0669cd71e65d3d8109c8cabde31cb6@localhost> #2298: renameFile is not atomic on Windows -----------------------+---------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------+---------------------------------------------------- The Haskell 98 spec says about `renameFile` Computation `renameFile old new` changes the name of an existing file system object from old to new. If the new object already exists, it is atomically replaced by the old object. The `renameFile` function has been tricky on Windows historically because Windows 9x did not directly support overwriting an existing file. Windows NT and later support [http://msdn.microsoft.com/en- us/library/aa365240(VS.85).aspx `MoveFileEx`] which has a flag `MOVEFILE_REPLACE_EXISTING`. The current `__hscore_renameFile` implementation for Windows uses a complex range of tests and workarounds to allow overwriting of existing files. Of course this cannot be atomic. For Windows NT it does use `MoveFileEx()` but then if that fails it goes and tries the old tricks anyway! So abandoning all promises of atomicity it goes and tries to delete the target file and then a final attempt to rename over the now- deleted target file. As far as I can see this is bonkers. It should use `MoveFileEx()` exactly once and if that fails then the whole thing fails. That way we preserve any atomicity guarantees that `MoveFileEx()` might provide. Note that the MSDN documentation doesn't actually say if the rename is atomic, even in the case of two files in the same directory. With a `renameFile` that ''does'' meet the H98 requirement we can write an `writeFileAtomic` function that either succeeds and replaces the target file or fails without altering the target file in any way. Additionally, other threads or processes will not see any intermediate states of the target file (though they would see the temp file created in the same directory). This is how text editors etc implement reliable file writing. Glib has a function like this [http://library.gnome.org/devel/glib/stable /glib-File-Utilities.html#g-file-set-contents g-file-set-contents]. {{{ writeFileAtomic :: FilePath -> String -> IO () writeFileAtomic targetFile content = Exception.bracketOnError (openTempFile targetDir template) (\(tmpFile, tmpHandle) -> hClose tmpHandle >> removeFile tmpFile) (\(tmpFile, tmpHandle) -> hPutStr tmpHandle content >> hClose tmpHandle >> renameFile tmpFile targetFile) where template = targetName <.> "tmp" (targetDir,targetName) = splitFileName targetFile }}} Indeed it's not impossible to imagine using this or something similar for the actual H98 `writeFile` implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 14:14:08 2008 From: trac at galois.com (GHC) Date: Tue May 20 14:07:34 2008 Subject: [GHC] #1963: Pressing ^C at the right moment can trash GHC's package list In-Reply-To: <044.fe68034f1a304106efaa8e4a323fded8@localhost> References: <044.fe68034f1a304106efaa8e4a323fded8@localhost> Message-ID: <053.618259b403e712ffd118b7a69daceb04@localhost> #1963: Pressing ^C at the right moment can trash GHC's package list ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by duncan): Replying to [comment:6 igloo]: > `writeFileAtomic` sounds like it belongs in `base`, not `Cabal`. Yeah it does. See #2298. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 16:27:11 2008 From: trac at galois.com (GHC) Date: Tue May 20 16:20:34 2008 Subject: [GHC] #2273: inlining defeats seq In-Reply-To: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> References: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> Message-ID: <053.7d47a82aeac400dce47e916279096187@localhost> #2273: inlining defeats seq ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by Isaac Dupree): are the following equivalent? {{{ a `fseq` \a' -> b `fseq` \b' -> (a',b') }}} {{{ b `fseq` \b' -> a `fseq` \a' -> (a',b') }}} (I guess this is the usual question where the order of strictness doesn't matter because "imprecise" exceptions? but the order might have non- obvious performance implications? It's simpler than `let` because it's not mutually/recursive by default...) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 16:47:26 2008 From: trac at galois.com (GHC) Date: Tue May 20 16:40:50 2008 Subject: [GHC] #1874: getDirectoryContents yields "invalid argument" instead of "permission error" In-Reply-To: <044.aea88e13611e8c8d6805f551748c45bd@localhost> References: <044.aea88e13611e8c8d6805f551748c45bd@localhost> Message-ID: <053.56c6aa411a4abce3c29aae43fe3a8d23@localhost> #1874: getDirectoryContents yields "invalid argument" instead of "permission error" ------------------------------------------------------------------+--------- Reporter: Orphi | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.8.3 Component: libraries/directory | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: getDirectoryContents "C:\\System Volume Information" | Architecture: x86 Os: Windows | ------------------------------------------------------------------+--------- Comment (by igloo): XP Pro, according to the welcome screen. Can you describe how you made the directory please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 16:42:52 2008 From: trac at galois.com (GHC) Date: Tue May 20 16:42:53 2008 Subject: [GHC] #2263: GHC 6.8 (STABLE) branch build framework does not pass correctly CPPFLAGS/LDFLAGS env vars to subsequent configure scripts In-Reply-To: <046.23fe9035121b5553a5c8813359d72f0f@localhost> References: <046.23fe9035121b5553a5c8813359d72f0f@localhost> Message-ID: <055.580ed86faf58614417af2038307173fc@localhost> #2263: GHC 6.8 (STABLE) branch build framework does not pass correctly CPPFLAGS/LDFLAGS env vars to subsequent configure scripts --------------------------+------------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Changes (by igloo): * status: reopened => closed * difficulty: => Unknown * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 16:44:53 2008 From: trac at galois.com (GHC) Date: Tue May 20 16:44:37 2008 Subject: [GHC] #2265: GHC 6.8 (STABLE) autoconf version requirements issue In-Reply-To: <046.cca200a2c8f3c0dc4698eeb862b6f329@localhost> References: <046.cca200a2c8f3c0dc4698eeb862b6f329@localhost> Message-ID: <055.e1c5926c4cd72cdfea793f5467392404@localhost> #2265: GHC 6.8 (STABLE) autoconf version requirements issue --------------------------+------------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: low | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Changes (by igloo): * priority: normal => low * difficulty: => Unknown * milestone: => 6.8.3 Comment: Can you attach a log of a clean build going wrong with 2.62, please, including all the commands that you run? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 17:02:06 2008 From: trac at galois.com (GHC) Date: Tue May 20 16:56:09 2008 Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost> References: <050.c31695132cb1b93380c95a8b6c208782@localhost> Message-ID: <059.e99d6f16d4756b0304b894f11eeb0ae3@localhost> #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: closed Priority: high | Milestone: Not GHC Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: OK, so I think we may as well close this bug then. Thanks everyone! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 19:54:27 2008 From: trac at galois.com (GHC) Date: Tue May 20 19:47:54 2008 Subject: [GHC] #2299: Haddock 2 library documentation not available Message-ID: <043.5ba8789d725e6cac9d84914b23770e98@localhost> #2299: Haddock 2 library documentation not available ------------------------+--------------------------------------------------- Reporter: fons | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- As you know, the .haddock files generated by haddock-0.8 are incompatible with haddock-2.X However, GHC's site only seems to offer a 0.8-friendly documentation package. I think GHC should systematically offer an alternative haddock-2 documentation package or, even better, provide documentation compatible with both versions (this would probably require changes in haddock). It would maybe be agood idea to offer http://www.haskell.org/ghc/docs/latest/libraries.html-haddock2.tar.gz apart from http://www.haskell.org/ghc/docs/latest/libraries.html.tar.gz or simply move on to haddock 2. Since most of my code relies on GHC syntax extensions and I didn't want to lose the ability to get links in my documentation, I created a haddock-2 version of the library documentation myself: http://code.haskell.org/~fons/libraries.html-haddock2.tgz Should I add the link to http://haskell.org/haskellwiki/GHC or wait until a cleaner solution is found? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 20:26:25 2008 From: trac at galois.com (GHC) Date: Tue May 20 20:19:48 2008 Subject: [GHC] #1963: Pressing ^C at the right moment can trash GHC's package list In-Reply-To: <044.fe68034f1a304106efaa8e4a323fded8@localhost> References: <044.fe68034f1a304106efaa8e4a323fded8@localhost> Message-ID: <053.8ee7f2ea8716871fece3c082631a52a4@localhost> #1963: Pressing ^C at the right moment can trash GHC's package list ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * type: merge => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 20 20:34:26 2008 From: trac at galois.com (GHC) Date: Tue May 20 20:27:48 2008 Subject: [GHC] #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc In-Reply-To: <050.7b39faa855e94ccd0c6858657071f62f@localhost> References: <050.7b39faa855e94ccd0c6858657071f62f@localhost> Message-ID: <059.7173316c88dbf40a75700fbb31b0add3@localhost> #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 21 00:08:44 2008 From: trac at galois.com (GHC) Date: Wed May 21 00:02:07 2008 Subject: [GHC] #2300: GHCi locks up on long input Message-ID: <042.b8baab5f9560c1bc1ba314b7db87b0d2@localhost> #2300: GHCi locks up on long input ------------------------+--------------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- When I enter a long entry into GHCi, it sometimes freezes up, completely locking the xterm. It doesn't respond to control-C, typing, arrow keys, or even pkill run from another terminal. The only way I have been able to get out of it is by closing the terminal. I'm having trouble reproducing the bug, but one such input that caused the problem was {{{ Prelude Text.XHtml.Strict> let f = renderHtml $ header (thetitle << "The Iliad") +++ body ((div << (h1 << "The Iliad" +++ cite << "Homer" +++ paragraph << "751 +++ body ((div << (h1 << "The Iliad" +++ cite << "Homer" +++ paragraph << "751 BC" +++ "Sing, O goddess, the rage of Achilles son of Peleus, that brought countless ills upon the Achaeans. Many a brave soul did it send hurrying down to Hades, and many a hero did it yield a prey to dogs and vultures, for so were the counsels of Jove fulfilled from the day on which the son of Atreus, king of men, and great Achilles, first fell out with one another" +++ paragraph << "And which of the gods was it that set them on to quarrel? It was the son of Jove and Leto; for he was angry with the king and sent a pestilence upon the host to plague the people, because the son of Atreus had dishonoured Chryses his priest. Now Chryses had come to the ships of the Achaeans to free his daughter, and had brought with him a great ransom: moreover he bore in his hand the sceptre of Apollo wreathed with a suppliant's wreath and he besought the Achaeans, but most of all the two sons of Atreus, who were their chiefs." ))) However, this input does not always cause the lockup. I will try to investigate more and try to get a more concrete test case, but I have not yet found a pattern to how this happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 21 04:17:11 2008 From: trac at galois.com (GHC) Date: Wed May 21 04:10:33 2008 Subject: [GHC] #2273: inlining defeats seq In-Reply-To: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> References: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> Message-ID: <053.425573269309c0683087ba696d2cecd5@localhost> #2273: inlining defeats seq ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): They are semantically equivalent, but could perhaps have different space behaviour. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 21 05:07:40 2008 From: trac at galois.com (GHC) Date: Wed May 21 05:01:01 2008 Subject: [GHC] #2293: Multiple declaration error shown multiple times In-Reply-To: <051.ed7e1c8300f38a10ee6d2df1bb501c8b@localhost> References: <051.ed7e1c8300f38a10ee6d2df1bb501c8b@localhost> Message-ID: <060.f030c948f43ebf4aa0666be1550e9f7e@localhost> #2293: Multiple declaration error shown multiple times --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rn_dup | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by simonpj): * testcase: => rn_dup * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: Good suggestion. I couldn't resist fixing this. I think we'll leave the fix in the HEAD only though. {{{ Tue May 20 15:30:06 BST 2008 simonpj@microsoft.com * Fix Trac #2293: improve error reporting for duplicate declarations }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 21 05:09:15 2008 From: trac at galois.com (GHC) Date: Wed May 21 05:02:35 2008 Subject: [GHC] #2292: Poor error message if type signature lacks definition In-Reply-To: <051.036bd49704eab0601f4378d15f12016d@localhost> References: <051.036bd49704eab0601f4378d15f12016d@localhost> Message-ID: <060.c1b4be3b316d1c96c606c0bdbb43ab48@localhost> #2292: Poor error message if type signature lacks definition --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Also good suggestion. Now we say: {{{ The type signature for `nub' lacks an accompanying binding }}} The patch is this (again I think not worth merging to branch unless it's v easy). {{{ Tue May 20 15:30:48 BST 2008 simonpj@microsoft.com * Fix Trac #2292: improve error message for lone signatures }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 21 07:19:35 2008 From: trac at galois.com (GHC) Date: Wed May 21 07:12:57 2008 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT Message-ID: <045.f06a53427920f75d02000e2372e27573@localhost> #2301: Proper handling of SIGINT/SIGQUIT ------------------------+--------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Multiple ------------------------+--------------------------------------------------- This guide http://www.cons.org/cracauer/sigint.html suggests a couple things that we should do that we do not currently do. It comes in two parts. 1. how we respond to our own calling process when we terminate due to `^C` 1. how we respond to process that we call terminating due to `^C` The first part is easier. If we decide that we want to terminate in response to a `^C` signal then it is important that our calling process knows that. We must kill ourselves using `SIGINT` and not just terminate via `exit()` otherwise our calling process must assume that we decided to ignore the `^C`. We should use `killpid(getpid(),SIGINT)`. Of course we may well want to catch `^C` and do cleanup work by unwinding all exception handlers etc. It is therefore important to distinguish `^C` from other exceptions so that when the `^C` exception propagates to the top level exception handler we have enough information to know to use `killpid(getpid(),SIGINT)` rather than just `exit(1)`. So we should add an `Interrupted` case to the `Exception` type. How we respond to `^C` while running sub-processes is more subtle. If we are delegating interaction with the user via the controlling terminal then we should also delegate the decision about how to respond to `^C`. Some child processes will also want to take cleanup action on `^C` or ignore it completely (eg ghci) so it is not right for us the parent process to catch `^C` and decide what to do. So where we are delegating the decision we should ignore `^C`. When we wait for a child process to terminate and discover that it exited due to `SIGINT` then at that moment we should respond in the same way as if we ourselves had received a `^C`. A sensible default might be to send the `Interrupted` exception to every thread in the system, or at least to the main thread. A haskell program can always change the response to `^C` by using `installHandler` (eg for an interactive REPL program like ghci). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 21 09:04:40 2008 From: trac at galois.com (GHC) Date: Wed May 21 08:58:00 2008 Subject: [GHC] #1061: default class methods can be given too general a type as GHC tries to share them between instances In-Reply-To: <044.844f66ca4a26056df0ffe2da43b8e56b@localhost> References: <044.844f66ca4a26056df0ffe2da43b8e56b@localhost> Message-ID: <053.3130e1aaf10514b7f1c1c26371b7cd2c@localhost> #1061: default class methods can be given too general a type as GHC tries to share them between instances ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: tc199 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: I've finally gotten around to fixing this long-standing bug. I hope the patch will merge smoothly, but it affects quite a few lines of code, so it may not. If not, I'm not sure it's worth losing sleep over: no one is on the cc list. {{{ Wed May 21 14:00:28 BST 2008 simonpj@microsoft.com * Fix Trac #1061: refactor handling of default methods }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 21 10:50:01 2008 From: trac at galois.com (GHC) Date: Wed May 21 10:43:29 2008 Subject: [GHC] #1955: Heap profiling on Windows doesn't work In-Reply-To: <051.41700a7931b75f5016d260a75d133aed@localhost> References: <051.41700a7931b75f5016d260a75d133aed@localhost> Message-ID: <060.8cb3e5bf2f4bb11679a06b6d2cc832ba@localhost> #1955: Heap profiling on Windows doesn't work ----------------------------+----------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Windows | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 21 10:52:37 2008 From: trac at galois.com (GHC) Date: Wed May 21 10:45:58 2008 Subject: [GHC] #2002: problems with very large (list) literals In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> Message-ID: <060.f0d0e026dd71c46e5f96cc3e7e9e8be5@localhost> #2002: problems with very large (list) literals ------------------------------------------+--------------------------------- Reporter: Isaac Dupree | Owner: simonmar Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Changes (by igloo): * milestone: 6.8.3 => 6.10 branch Comment: I've merged {{{ Mon May 19 05:53:33 PDT 2008 Simon Marlow * bump GHC's maximum stack size to 64Mb (see #2002) }}} I'm not sure if there isn't more going on here, though, so I'm leaving the bug open but in the 6.10 milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 21 10:55:35 2008 From: trac at galois.com (GHC) Date: Wed May 21 10:49:13 2008 Subject: [GHC] #2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid argument (Invalid argument)" In-Reply-To: <045.9f2f177f681138fbf7d90d1273238fd5@localhost> References: <045.9f2f177f681138fbf7d90d1273238fd5@localhost> Message-ID: <054.c7aa5281db8ea5b2e792c39734b8b9ed@localhost> #2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid argument (Invalid argument)" -----------------------------------+---------------------------------------- Reporter: slyfox | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.8.3 Component: libraries/unix | Version: 6.8.2 Severity: major | Resolution: fixed Keywords: regression, ffi, unix | Difficulty: Unknown Testcase: resourceLimit | Architecture: x86 Os: Linux | -----------------------------------+---------------------------------------- Changes (by igloo): * testcase: => resourceLimit * status: new => closed * resolution: => fixed Comment: I've fixed this for `getrlimit`, `setrlimit` and `mkstemp`; I didn't find any other problematic cases. The fix is in both the HEAD and the 6.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 21 14:01:29 2008 From: trac at galois.com (GHC) Date: Wed May 21 13:54:51 2008 Subject: [GHC] #2302: error messages mangle unicode characters Message-ID: <044.147efe59df054c7c5210f4aae33a16fd@localhost> #2302: error messages mangle unicode characters ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- ghc/ghci understand source code written in UTF-8. However, an error message that contains such characters will turn them into gibberish. This is especially annoying in ghci: {{{ *> ? :1:0: Not in scope: `?' *> ? :1:0: Not in scope: data constructor `*' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 21 14:08:52 2008 From: trac at galois.com (GHC) Date: Wed May 21 14:02:12 2008 Subject: [GHC] #2303: unicode: nko characters can't be used in string literals Message-ID: <044.70e2afcd767b6042756ff0b013e94c28@localhost> #2303: unicode: nko characters can't be used in string literals ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- This bug affects the lexer in ghc(i): {{{ *> "?" :1:1: lexical error in string/character literal at character '\2015' }}} Similar errors result from characters U+7C0 .. U+7C9 (nko digits) and probably many others. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 21 14:15:36 2008 From: trac at galois.com (GHC) Date: Wed May 21 14:08:55 2008 Subject: [GHC] #2304: unicode digits misparsed in escape sequences Message-ID: <044.64b9e7c640fc035d36b9efb36b933234@localhost> #2304: unicode digits misparsed in escape sequences ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- {{{ *> "\?" *** Exception: parser/Ctype.lhs:(91,13)-(347,35): Non-exhaustive patterns in case *> "\?" *** Exception: parser/Ctype.lhs:(91,13)-(347,35): Non-exhaustive patterns in case }}} I haven't seen ghc's code, but I bet it uses something like `let (digits, str') = span isDigit str in chr (read digits) : parse str'` to process escape sequences in string/character literals. This is broken because `isDigit` returns `True` for a lot of non-`['0'..'9']` characters, such as subscripts, Thai digits, double-wide digits, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 21 15:21:25 2008 From: trac at galois.com (GHC) Date: Wed May 21 15:21:21 2008 Subject: [GHC] #2265: GHC 6.8 (STABLE) autoconf version requirements issue In-Reply-To: <046.cca200a2c8f3c0dc4698eeb862b6f329@localhost> References: <046.cca200a2c8f3c0dc4698eeb862b6f329@localhost> Message-ID: <055.8b41edde61808284607e336a94e12c03@localhost> #2265: GHC 6.8 (STABLE) autoconf version requirements issue --------------------------+------------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: low | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by kgardas): OK, I've basically downloaded ghc-STABLE-2007-09-11-ghc-corelibs- testsuite.tar.bz2 and unpacked it in /var/tmp, then cd /var/tmp/ghc, darcs pull -a, chmod +x darcs-all, darcs-all pull -a and then did what's in log files. To be honest I'm not able to build current STABLE with neither autoconf 2.62 nor with 2.59 (which worked before, but I have forgotten how :-). Well, anyway, autoconf 2.62 produces quite suspicious warnings and they are logged in the log file. For your reference I also provided log file from autoconf 2.59 build. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 21 17:43:31 2008 From: trac at galois.com (GHC) Date: Wed May 21 17:36:50 2008 Subject: [GHC] #1061: default class methods can be given too general a type as GHC tries to share them between instances In-Reply-To: <044.844f66ca4a26056df0ffe2da43b8e56b@localhost> References: <044.844f66ca4a26056df0ffe2da43b8e56b@localhost> Message-ID: <053.2812817c492da0b93180c16b26342edd@localhost> #1061: default class methods can be given too general a type as GHC tries to share them between instances ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: tc199 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Didn't merge cleanly, so not merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 22 01:07:53 2008 From: trac at galois.com (GHC) Date: Thu May 22 01:01:11 2008 Subject: [GHC] #2300: GHCi locks up on long input In-Reply-To: <042.b8baab5f9560c1bc1ba314b7db87b0d2@localhost> References: <042.b8baab5f9560c1bc1ba314b7db87b0d2@localhost> Message-ID: <051.2cbaee52f4c67aa7a7b7e9b5faab1f26@localhost> #2300: GHCi locks up on long input ------------------------+--------------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- Comment (by ajd): Actually, the length of the input doesn't seem to matter---GHCi just freezes up randomly. From a recent session: {{{ $ ghci Parser2.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Parser2 ( Parser2.hs, interpreted Ok, modules loaded: Parser2. *Parser2> parseTest tagOpen "" Loading package array-0.1.0.0 ... linking ... done. Loading package bytestring-0.9.0.1 ... linking ... done. Loading package mtl-1.1.0.0 ... linking ... done. Loading package parsec-3.0.0 ... linking ... done. ("foo",[]) *Parser2> parseTest tagOpen "" parse error at (line 1, column 5): unexpected "/" expecting letter or digit, white space or ">" *Parser2> parseTest tagOpen "" *** Exception: Prelude.undefined *Parser2> parseTest tagOpen "" *** Exception: Prelude.undefined *Parser2> :e *Parser2> :r [1 of 1] Compiling Parser2 ( Parser2.hs, interpreted Ok, modules loaded: Parser2. *Parser2> parseTest tagOpen "" ("foo",[("foo","bar")]) *Parser2> parseTest tagOpen "" ("foo",[("foo","bar"),("bar","bat")]) *Parser2> parseTest tagOpen " ("foo",[("foo","bar"),("bar","bat"),("bar","bat")]) *Parser2> parseTest tagOpen " parseTest tagOpen " parseTest tagOpen " ("foo",[("foo","bar"),("bar","bat"),("bar","bat")]) *Parser2> :e *Parser2> :r [1 of 1] Compiling Parser2 ( Parser2.hs, interpreted Ok, modules loaded: Parser2. *Parser2> parseTest (tagClose "boo" }}} At this point, the session doesn't respond to further input. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 22 04:21:46 2008 From: trac at galois.com (GHC) Date: Thu May 22 04:15:08 2008 Subject: [GHC] #1874: getDirectoryContents yields "invalid argument" instead of "permission error" In-Reply-To: <044.aea88e13611e8c8d6805f551748c45bd@localhost> References: <044.aea88e13611e8c8d6805f551748c45bd@localhost> Message-ID: <053.0eac9c6d57fce3710aa2ace55299a7b4@localhost> #1874: getDirectoryContents yields "invalid argument" instead of "permission error" ------------------------------------------------------------------+--------- Reporter: Orphi | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.8.3 Component: libraries/directory | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: getDirectoryContents "C:\\System Volume Information" | Architecture: x86 Os: Windows | ------------------------------------------------------------------+--------- Comment (by Deewiant): One way is to use the Cygwin shell: {{{ $ mkdir npd $ chmod goa-rwx npd }}} The other way is to use the Windows GUI. In Windows Explorer: create the directory, view its Properties (via right-click or File menu), go to the Security tab, and set "Full Control" to "Deny" for all groups and user names (I think setting any one which applies to you is sufficient, but I set all just in case). In either case, I get "invalid argument" out of `getDirectoryContents`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 22 05:13:30 2008 From: trac at galois.com (GHC) Date: Thu May 22 05:06:50 2008 Subject: [GHC] #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.cdd53af2cd1be24e20e2344275815615@localhost> #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP --------------------------------------------+------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Comment (by judah): There is code in {{{base/cbits/consUtils.c:set_console_buffering}}} to disable Windows line buffering (by calling the Win32 function `SetConsoleMode`). However, the code in `GHC.Handle` which is supposed to call that function was `#ifdef`'ed out on mingw in the following commit: http://cvs.haskell.org/cgi- bin/cvsweb.cgi/fptools/libraries/base/GHC/Handle.hs#rev1.14 From the comments in `System.Posix.Internals`: {{{ -- 'raw' mode for Win32 means turn off 'line input' (=> buffering and -- character translation for the console.) The Win32 API for doing -- this is GetConsoleMode(), which also requires echoing to be disabled -- when turning off 'line input' processing. Notice that turning off -- 'line input' implies enter/return is reported as '\r' (and it won't -- report that character until another character is input..odd.) This -- latter feature doesn't sit too well with IO actions like IO.hGetLine.. }}} I'm not that experienced with Windows programming, but maybe instead of changing the `ConsoleMode`, we could call the lower-level `ReadConsoleInput/PeekConsoleInput` when we want to read only one character at a time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 22 05:25:17 2008 From: trac at galois.com (GHC) Date: Thu May 22 05:18:35 2008 Subject: [GHC] #2305: GHC does not care __RENAME macro Message-ID: <044.e399572fbb2da5bdb111ddafffcbdbb1@localhost> #2305: GHC does not care __RENAME macro --------------------------------+------------------------------------------- Reporter: iquiw | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: NetBSD --------------------------------+------------------------------------------- == Problem == GHC+FFI does not use correct symbol if `__RENAME` macro is used. == Background == NetBSD uses `__RENAME` macro to solve compatibility issue of different versioned shared library. For example, the following line is in /usr/include/locale.h. {{{ char *setlocale(int, const char *) __RENAME(__setlocale_mb_len_max_32); }}} If setlocale() is called from C source that includes "locale.h", then it is linked to symbol `__setlocale_mb_len_max_32` after compiled. GHC (-fasm) does not do this.[[BR]] If GHC option -fvia-C is specified, then correct symbol is used == Example == `__RENAME(foo)` is actually expanded as `__asm("foo")`. So the following codes simulate the problem. rename.h {{{ int foo() __asm("bar"); }}} rename.c {{{ int foo() { return 1; } int bar() { return 2; } }}} main.hs {{{ foreign import ccall unsafe "rename.h" foo :: IO Int main = foo >>= print }}} (1) -fvia-C(OK) {{{ $ ghc -fvia-C -ffi main.hs rename.c && ./a.out 2 }}} (2) -fasm (OK) {{{ $ ghc -fasm -ffi main.hs rename.c && ./a.out 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 22 05:40:22 2008 From: trac at galois.com (GHC) Date: Thu May 22 05:33:40 2008 Subject: [GHC] #2305: GHC does not care __RENAME macro In-Reply-To: <044.e399572fbb2da5bdb111ddafffcbdbb1@localhost> References: <044.e399572fbb2da5bdb111ddafffcbdbb1@localhost> Message-ID: <053.b537f75e01963e30ab405108ff16ee00@localhost> #2305: GHC does not care __RENAME macro --------------------------------+------------------------------------------- Reporter: iquiw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: NetBSD --------------------------------+------------------------------------------- Comment (by iquiw): {{{ - (2) -fasm (OK) + (2) -fasm (NG) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 22 11:27:21 2008 From: trac at galois.com (GHC) Date: Thu May 22 11:20:43 2008 Subject: [GHC] #2306: The (^) operator sometimes uses one (*) more than needed. Message-ID: <044.dff49bec25ebc555eb9d893ae67998f1@localhost> #2306: The (^) operator sometimes uses one (*) more than needed. ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Prelude Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- The implementation of integer exponentiation is suboptimal. By inserting a trace in (*) you can easily observe that, e.g., exponent 4 uses 3 multiplications instead of 2. Here's a different version: {{{ (^) :: (Num a, Integral b) => a -> b -> a _ ^ 0 = 1 x ^ n | n > 0 = g x n where g b i | even i = g (b*b) (i `quot` 2) | otherwise = f b (i-1) b f _ 0 y = y f a d y | even d = f (a*a) (d `quot` 2) y | otherwise = f a (d-1) (a * y) _ ^ _ = error "Prelude.^: negative exponent" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 23 08:13:38 2008 From: trac at galois.com (GHC) Date: Fri May 23 08:06:53 2008 Subject: [GHC] #1558: make the testsuite work with THREADS=2 In-Reply-To: <047.86273a610439c0814c0caa79ac522fd9@localhost> References: <047.86273a610439c0814c0caa79ac522fd9@localhost> Message-ID: <056.179876532a7620fab83fe3116dbd1047@localhost> #1558: make the testsuite work with THREADS=2 ------------------------+--------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Test Suite | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ------------------------+--------------------------------------------------- Comment (by igloo): Having had a quick look at the above bug report and the code, I think that this has been fixed. In my python 2.4.4 I have {{{ def _cleanup(): for inst in _active[:]: inst.poll() }}} (`poll` calls `_active.remove(self)`) while in my 2.5.2 I have {{{ def _cleanup(): for inst in _active[:]: if inst.poll(_deadstate=sys.maxint) >= 0: try: _active.remove(inst) except ValueError: # This can happen if two threads create a new Popen instance. # It's harmless that it was already removed, so ignore. pass }}} and I think that caught exception is the one that we are seeing. Even if it is not fixed, I think that we could work around it by wrapping the Popen class in our own class, and taking a lock before calling the Popen constructor. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 23 10:26:12 2008 From: trac at galois.com (GHC) Date: Fri May 23 10:19:27 2008 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@localhost> References: <047.24a366415ff9b59c03e5bf49850898a6@localhost> Message-ID: <056.afaf43ac14b8122935f3e027f3a4befa@localhost> #2233: Overhaul System.Process -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/process | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by duncan): Further to the changes already made we discussed some ideas on #ghc today: Deprecate: * `runCommand` * `runProcess` * `runInteractiveCommand` * `runInteractiveCommand` The rationale is that these are all more limited than the new `createProcess` and yet none of them are really convenient. It's better to have fewer variations if they can all be expressed easily using `createProcess`. It makes the API much simpler. Also we'd not add `system` or `rawSystem` to `System.Process`. That would leave just: * `createProcess` * `readProcess` * `readProcessWithExitCode` Then add the following: * `callProcess :: FilePath -> [String] -> IO ()` * `callCommand :: String -> IO ()` These would be synchronous like the current `system` and `rawSystem`. The difference is they would throw `IOError`s on failure rather than returning the `ExitCode` which is so easily ignored. These are of course only convenience functions. If someone wants the exit code it should be easy to do it via `createProcess` and `waitForProcess`. We need to make sure that is indeed the case. We'd also add async versions of the above: * `spawnProcess :: FilePath -> [String] -> IO ProcessHandle` * `spawnCommand :: String -> IO ProcessHandle` that do not wait for the process to finish and return the ProcessHandle. Again these should be easy instances of `createProcess`. The docs should probably say as much so it's clear how to make minor variations. We also discussed how it should be safe to GC the `ProcessHandle` and not end up with zombie processes on unix systems. On Windows it's actually easy because you can close the process handle which means you don't get the exit status of the process. On unix we have to collect the exit status of every child process (actually you can ignore all of them, but you cannot ignore them selectively). The point is that with a convenient `spawnProcess` it's tempting to ignore the `ProcessHandle` result and never bother calling `waitForProcess` on it. We do want to support that. At the moment doing that would leave zombie processes. We discussed a mechanism to allow GC'ing `ProcessHandle`s that does not leave zombies. It'd probably involve keeping a `Map PID (MVar ExitCode)` and embedding a `MVar ExitCode` in the `ProcessHandle`. Then when we get notified that a child process terminated we would store the exit status in the `MVar`. Then `waitForProcess` would just wait on that `MVar ExitCode`. The one thing we have left that we cannot express with `createProcess` is the behavior with respect to `^C` handling. For some processes we want to delegate `^C` handling to that child process (eg imagine calling `ghci`). For others we want to handle `^C` 'normally'. For details see #2301. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 23 10:33:09 2008 From: trac at galois.com (GHC) Date: Fri May 23 10:26:24 2008 Subject: [GHC] #1415: Provide a way to runInteractiveCommand without passing all your filedescriptors In-Reply-To: <044.b269c673165d64cf3a451e210e04330b@localhost> References: <044.b269c673165d64cf3a451e210e04330b@localhost> Message-ID: <053.63d7f40bf9ef69df1885c6c0482071ce@localhost> #1415: Provide a way to runInteractiveCommand without passing all your filedescriptors -------------------------------+-------------------------------------------- Reporter: igloo | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 6.10 branch Component: libraries/process | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Now done, in the System.Process overhaul (#2233). You pass a `CreateProcess` record with `close_fds=True` when calling `createProcess`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 23 11:28:16 2008 From: trac at galois.com (GHC) Date: Fri May 23 11:21:33 2008 Subject: [GHC] #2307: Poor warning for conflicting functional dependencies Message-ID: <051.74da8f65a0dfd1e30516012444a9f297@localhost> #2307: Poor warning for conflicting functional dependencies -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- {{{ E:\Neil\thesis>ghci obj\haskell2\Proof_default.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Proof_default ( obj/haskell2/Proof_default.hs, interpreted ) obj/haskell2/Proof_default.hs:177:0: Functional dependencies conflict between instance declarations: instance [incoherent] SubstRep (Prop (Sat VarName)) ([VarName], [Expr]) (Prop (Sa t Expr)) -- Defined at obj/haskell2/Proof_default.hs:177:0-75 instance [incoherent] SubstRep (Prop (Sat Int)) ([Int], [Expr]) (Prop (Sat Expr)) -- Defined at obj/haskell2/Proof_default.hs:180:0-67 instance [incoherent] SubstRep (Prop (Sat Int)) ([Int], [Expr]) (Prop (Sat Expr)) -- Defined at obj/haskell2/Proof_default.hs:180:0-67 Failed, modules loaded: none. }}} It has listed three items that conflict, but two of the items are actually the same. I would expect the error message to {{{nub}}} the list of instances first. Sample file attached. This bug may have been fixed in HEAD, with the recent warnings patch, but I cannot check (not enough disk space!). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 23 11:28:19 2008 From: trac at galois.com (GHC) Date: Fri May 23 11:21:36 2008 Subject: [GHC] #2273: inlining defeats seq In-Reply-To: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> References: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> Message-ID: <053.0512262ba110c54ffd535f750ef57e2f@localhost> #2273: inlining defeats seq ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 23 12:54:04 2008 From: trac at galois.com (GHC) Date: Fri May 23 12:47:19 2008 Subject: [GHC] #1657: throwTo + unsafeInterleaveIO oddness In-Reply-To: <044.21440a48538e444ebfd4d18aeba61e97@localhost> References: <044.21440a48538e444ebfd4d18aeba61e97@localhost> Message-ID: <053.21a99a8cad1415cb98dd838123a06636@localhost> #1657: throwTo + unsafeInterleaveIO oddness ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: 6.8.3 => _|_ Comment: OK, the good news is that it looks like the program is now segfault-free on Linux and Windows, with this additional patch: {{{ Fri May 23 04:25:08 BST 2008 Ian Lynagh * Do some stack fiddling in stg_unblockAsyncExceptionszh_ret This fixes a segfault in #1657 }}} The bad news is that Simon Marlow says that the behaviour (that a single throwTo causes the computation not to be resumable) is expected given the way exceptions are currently implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From dons at galois.com Fri May 23 14:33:48 2008 From: dons at galois.com (Don Stewart) Date: Fri May 23 14:27:09 2008 Subject: [Haskell-cafe] Bug in parallel GHC runtime? In-Reply-To: <4836DAAF.7090701@fit.vutbr.cz> References: <4836DAAF.7090701@fit.vutbr.cz> Message-ID: <20080523183348.GE4034@scytale.galois.com> Hi, Thanks for the bug report. This should be filed on the GHC bug tracker, http://hackage.haskell.org/trac/ghc/newticket?type=bug And I've forwarded it to the glasgow-haskell-bugs mailing list. kolar: > Hello all, > > The attached file was compiled by the following command: > > ghc -O2 --make -threaded ltest1pl.hs -o alall > > When run in a sequential mode, I get this result: > ./alall > Starting ... > Lst1: 41666666650000 > Lst2: 41669166700000 > T1: 0m 1.0e-6s > 36 > End! > > > On the other hand, when run in a threaded mode, I get the following error: > ./alall +RTS -N2 > Starting ... > Lst1: 41666666650000 > Lst2: 41669166700000 > T1: 0m 0.0s > Segmentation fault > > Is it fault of the GHC runtime, or is it something on my side? > > > My machine: uname -a > Linux pc 2.6.24-ARCH #1 SMP PREEMPT Sun Mar 30 10:50:22 CEST 2008 x86_64 > Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux > > My ghc: ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.8.2 > > > Thanks and regards > Dusan > > --import Control.Concurrent > --import Control.Concurrent.MVar > import System.Time > > import Control.Parallel.Strategies > > --import Data.List (foldl') > import qualified Data.ByteString as B > > > sumAllSums [] = 0 > sumAllSums l@(_:xs) = sumlist 0 l + sumAllSums xs > where sumlist res [] = res > sumlist sr (v:vs) = sumlist (sr+v) vs > > wlist2wbs [] = B.pack [] > wlist2wbs l@(_:_) = B.pack $ encode l > where > encode :: Integral a => [Int] -> [a] > encode [] = [] > encode (x:xs) = > if x==0 then 0:0:encode xs > else fromIntegral (x `mod` 256) : fromIntegral (x `div` 256) : encode xs > > main = do > putStrLn $ "Starting ..." > let lst1 = [0..49999] > let lst2 = [0..50000] > let bs1 = wlist2wbs lst1 > let bs2 = wlist2wbs lst2 > tm1 <- getClockTime > let (v1:v2:_) = parMap rnf sumAllSums [lst1,lst2] > tm1' <- getClockTime > putStrLn ("Lst1: " ++ show v1) > putStrLn ("Lst2: " ++ show v2) > let tdiff1 = diffClockTimes tm1' tm1 > --let tdiff2 = diffClockTimes tm2' tm2 > putStrLn $ "T1: " ++ show (tdMin tdiff1) ++ "m " ++ show (fromIntegral(tdSec tdiff1) + fromIntegral(tdPicosec tdiff1)/1e12) ++ "s" > --putStrLn $ "T2: " ++ show (tdMin tdiff2) ++ "m " ++ show (fromIntegral(tdSec tdiff2) + fromIntegral(tdPicosec tdiff2)/1e12) ++ "s" > putStrLn $ show $ {-ibs1 +-} B.index bs1 99999 + B.index bs2 49999 {-((bs1 + fromIntegral (B.index bs2 99999)) :: Integer)-} > putStrLn $ "End!" > > {- > main = do > tm1 <- getClockTime > putStrLn $ "Starting ... " > mv1 <- newEmptyMVar > mv2 <- newEmptyMVar > t1 <- forkIO (putMVar mv1 $! sumAllSums [0..49999]) > t2 <- forkIO (putMVar mv2 $! sumAllSums [1..50000]) > v1 <- takeMVar mv1 > v2 <- takeMVar mv2 > killThread t1 > killThread t2 > putStrLn $ "Result: " ++ show (v1+v2) > tm2 <- getClockTime > let tdiff = diffClockTimes tm2 tm1 > putStrLn $ "End! " ++ show (tdMin tdiff) ++ "m " ++ show (fromIntegral(tdSec tdiff) + fromIntegral(tdPicosec tdiff)/1e12) ++ "s" > -} > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From trac at galois.com Fri May 23 21:30:03 2008 From: trac at galois.com (GHC) Date: Fri May 23 21:23:15 2008 Subject: [GHC] #1605: hppa port -- gmp handed misaligned memory In-Reply-To: <044.7ca61f85138b90c0e193b83a232b3207@localhost> References: <044.7ca61f85138b90c0e193b83a232b3207@localhost> Message-ID: <053.0675b46797aa5047f3ef5e86db4473c0@localhost> #1605: hppa port -- gmp handed misaligned memory ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: GMP | Difficulty: Easy (1 hr) Testcase: | Architecture: hppa Os: HPUX | ----------------------------+----------------------------------------------- Comment (by igloo): I think that something like this might be the way to go: {{{ diff -rN -u old-val/rts/PrimOps.cmm new-val/rts/PrimOps.cmm --- old-val/rts/PrimOps.cmm 2008-05-24 02:20:52.000000000 +0100 +++ new-val/rts/PrimOps.cmm 2008-05-24 02:21:06.000000000 +0100 @@ -546,23 +546,33 @@ /* ToDo: this is shockingly inefficient */ +#if defined(hpux_HOST_OS) +#define MP_ALIGN align 8; +#else +#define MP_ALIGN +#endif + #ifndef THREADED_RTS section "bss" { + MP_ALIGN mp_tmp1: bits8 [SIZEOF_MP_INT]; } section "bss" { + MP_ALIGN mp_tmp2: bits8 [SIZEOF_MP_INT]; } section "bss" { + MP_ALIGN mp_result1: bits8 [SIZEOF_MP_INT]; } section "bss" { + MP_ALIGN mp_result2: bits8 [SIZEOF_MP_INT]; } @@ -691,6 +701,7 @@ #ifndef THREADED_RTS section "bss" { + MP_ALIGN mp_tmp_w: W_; // NB. mp_tmp_w is really an here mp_limb_t } #endif }}} but (in the HEAD) having the align on amd64/Linux gives me: {{{ ../compiler/ghc-inplace -Werror -H64m -Onot -fasm -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -fvia-C -static -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c PrimOps.cmm -o PrimOps.o ghc-6.9.20080523: panic! (the 'impossible' happened) (GHC version 6.9.20080523 for x86_64-unknown-linux): PprC.pprTop: can't handle this data Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [PrimOps.o] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 23 22:00:24 2008 From: trac at galois.com (GHC) Date: Fri May 23 21:59:56 2008 Subject: [GHC] #2308: ghc doesn't honor -keep-tmp-files Message-ID: <041.a3c63244dfb916edfa595a2a5f549242@localhost> #2308: ghc doesn't honor -keep-tmp-files -----------------------+---------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.6.1 | Severity: minor Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- ghc 6.6.1 doesn't keep any temporary files when given the {{{-keep-tmp- files}}} flag. The {{{-keep-s-file}}} flag appears to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 24 09:47:30 2008 From: trac at galois.com (GHC) Date: Sat May 24 09:40:41 2008 Subject: [GHC] #2231: GHC RTS Segfault In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.c8c496d9691e5c41780e7419bfbfb115@localhost> #2231: GHC RTS Segfault ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Comment (by igloo): I can't reproduce this on i386/Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 24 19:56:44 2008 From: trac at galois.com (GHC) Date: Sat May 24 19:49:53 2008 Subject: [GHC] #2309: containers: specialize functions that fail in a Monad to Maybe Message-ID: <043.a73cd7403da16bcdc6cc412935455c2a@localhost> #2309: containers: specialize functions that fail in a Monad to Maybe -------------------------+-------------------------------------------------- Reporter: ross | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Several functions on containers used to have types like {{{ lookup :: (Ord k) => k -> Map k a -> Maybe a }}} but these were generalized to {{{ lookup :: (Monad m, Ord k) => k -> Map k a -> m a }}} The only methods of `Monad` used are `return` and `fail`. The problem is that, depending on the monad, `fail` can be an ordinary value or a runtime error: this device makes it harder to check whether a program is safe, because it hides possible runtime errors among testable conditions. The proposal is to change these signatures back, specializing them to `Maybe`. The functions involved are: {{{ lookup :: Ord k => k -> Map k a -> Maybe a lookupIndex :: Ord k => k -> Map k a -> Maybe Int minViewWithKey :: Map k a -> Maybe ((k,a), Map k a) maxViewWithKey :: Map k a -> Maybe ((k,a), Map k a) minView :: Map k a -> Maybe (a, Map k a) maxView :: Map k a -> Maybe (a, Map k a) lookup :: Key -> IntMap a -> Maybe a maxViewWithKey :: IntMap a -> Maybe ((Key, a), IntMap a) minViewWithKey :: IntMap a -> Maybe ((Key, a), IntMap a) maxView :: IntMap a -> Maybe (a, IntMap a) minView :: IntMap a -> Maybe (a, IntMap a) minView :: Set a -> Maybe (a, Set a) maxView :: Set a -> Maybe (a, Set a) maxView :: IntSet -> Maybe (Int, IntSet) minView :: IntSet -> Maybe (Int, IntSet) }}} No information is lost, because in each case there is a single failure mode. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 24 20:07:31 2008 From: trac at galois.com (GHC) Date: Sat May 24 20:00:39 2008 Subject: [GHC] #2309: containers: specialize functions that fail in a Monad to Maybe In-Reply-To: <043.a73cd7403da16bcdc6cc412935455c2a@localhost> References: <043.a73cd7403da16bcdc6cc412935455c2a@localhost> Message-ID: <052.c4bfd4785b6f0bb12a1464ee2ebaa408@localhost> #2309: containers: specialize functions that fail in a Monad to Maybe ----------------------------------+----------------------------------------- Reporter: ross | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------+----------------------------------------- Comment (by ross): Deadline: Mon 23rd June (4 weeks) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 25 08:37:26 2008 From: trac at galois.com (GHC) Date: Sun May 25 08:30:35 2008 Subject: [GHC] #2164: zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd In-Reply-To: <044.65631559df6ce2cd79a1eb038ea82f5f@localhost> References: <044.65631559df6ce2cd79a1eb038ea82f5f@localhost> Message-ID: <053.42cf1662ed84eb49ff14edc526fc5716@localhost> #2164: zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd ----------------------------+----------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler (FFI) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Unknown | ----------------------------+----------------------------------------------- Comment (by wjt): I can trigger the same internal error on my x86 (Pentium M) with a different example, using gtk2hs, curl and HXT. The attached source file is as far as I can reduce it without the error going away, I'm afraid. The output given is: {{{ before GHC_bug_2164: internal error: task 0x842ccb8: main thread 1 has been GC'd (GHC version 6.8.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I cannot reproduce the error using the ZMachine code. {{{ 2071 % uname -a; ghc --info Linux talkie 2.6.24-1-686 #1 SMP Thu May 8 02:16:39 UTC 2008 i686 GNU/Linux [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","6.8.2") ,("Booter version","6.8.2") ,("Stage","2") ,("Interface file version","6") ,("Have interpreter","YES") ,("Object splitting","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("Win32 DLLs","") ,("RTS ways"," debug thr thr_p thr_debug debug_p thr_debug thr_debug_p") ,("Leading underscore","NO") ] 2083 % for i in gtk curl hxt; do ghc-pkg list $i; done /usr/lib/ghc-6.8.2/package.conf: gtk-0.9.12.1 /usr/lib/ghc-6.8.2/package.conf: curl-1.3.2 /usr/lib/ghc-6.8.2/package.conf: hxt-7.5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 25 21:18:46 2008 From: trac at galois.com (GHC) Date: Sun May 25 21:11:52 2008 Subject: [GHC] #2310: Panic in ghci 6.8.2 with -fglasgow-exts Message-ID: <044.6adffbe80c29ff86b9900afa24eb80ad@localhost> #2310: Panic in ghci 6.8.2 with -fglasgow-exts -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Steps to reproduce: 1. Run "ghci -fglasgow-exts" 2. Enter: "let const :: (forall a. (forall b. a->b)) = \x::a -> (\y -> x) :: (forall b. b -> a)". Result: {{{ GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> let const :: (forall a. (forall b. a->b)) = \x::a -> (\y -> x) :: (forall b. b -> a) ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): nameModule a{tv anJ} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Let me know if any more information would be helpful. This is all on a Ubuntu 8.04. I have included below the output of running the above with "ghci -v -fglasgow-exts": ghci -v {{{ GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted by GHC version 6.8.2 Using package config file: /usr/lib/ghc-6.8.2/package.conf wired-in package base mapped to base-3.0.1.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package template-haskell mapped to template-haskell-2.2.0.0 wired-in package ndp not found. Hsc static flags: -static *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package base ... linking ... done. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: Prelude> let const :: (forall a. (forall b. a->b)) = \x::a -> (\y -> x) :: (forall b. b -> a) *** Parser: ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): nameModule a{tv anJ} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 25 22:56:36 2008 From: trac at galois.com (GHC) Date: Sun May 25 22:49:42 2008 Subject: [GHC] #2310: Panic in ghci 6.8.2 with -fglasgow-exts In-Reply-To: <044.6adffbe80c29ff86b9900afa24eb80ad@localhost> References: <044.6adffbe80c29ff86b9900afa24eb80ad@localhost> Message-ID: <053.3d1f02cb233c3d3ba27f2b3883438dea@localhost> #2310: Panic in ghci 6.8.2 with -fglasgow-exts -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Comment (by guest): A little bit more info (following the wiki guidelines, although I don't know if any of this is useful): uname -a {{{ Linux 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux }}} gcc -v {{{ Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable- languages=c,c++,fortran,objc,obj-c++,treelang \ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib \ --without-included-gettext --enable-threads=posix --enable-nls \ --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu \ --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable- targets=all \ --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) }}} Adding the "-dcore-line" flags has no effect. The problem does not appear without the "-fglasgow-exts" flag: {{{ Prelude> let const :: (forall a. (forall b. a->b)) = \x::a -> (\y -> x) :: (forall b. b -> a) :1:4: Illegal signature in pattern: forall a . (forall b . (a -> b)) Use -XPatternSignatures to permit it :1:48: Illegal signature in pattern: a Use -XPatternSignatures to permit it :1:75: Illegal operator `.' in type `forall b . (b -> a)' (Use -XTypeOperators to allow operators in types) }}} 'Hope this helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 26 02:34:04 2008 From: trac at galois.com (GHC) Date: Mon May 26 02:27:21 2008 Subject: [GHC] #2311: hpc markup fails to create directory when marking up coverage of a package Message-ID: <047.c5e059546eb7b71abc6327141315c07f@localhost> #2311: hpc markup fails to create directory when marking up coverage of a package -------------------------+-------------------------------------------------- Reporter: AndyGill | Owner: andygill@ku.edu Type: bug | Status: new Priority: normal | Component: Code Coverage Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- When writing marked up html files, hpc markup does not create a directory, if needed, for packages. {{{ $ hpc markup --destdir=html Test --fun-entry-count --srcdir=. --srcdir=../../code/vector-space Writing: Test.hs.html Writing: vector-space-0.1.4/Data.Cross.hs.html hpc: html/vector-space-0.1.4/Data.Cross.hs.html: openFile: does not exist (No such file or directory) $ mkdir html/vector-space-0.1.4 $ hpc markup --destdir=html Test --fun-entry-count --srcdir=. --srcdir=../../code/vector-space Writing: Test.hs.html Writing: vector-space-0.1.4/Data.Cross.hs.html Writing: vector-space-0.1.4/Data.Derivative.hs.html Writing: vector-space-0.1.4/Data.NumInstances.hs.html Writing: vector-space-0.1.4/Data.VectorSpace.hs.html ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 26 07:17:09 2008 From: trac at galois.com (GHC) Date: Mon May 26 07:10:14 2008 Subject: [GHC] #2310: Panic in ghci 6.8.2 with -fglasgow-exts In-Reply-To: <044.6adffbe80c29ff86b9900afa24eb80ad@localhost> References: <044.6adffbe80c29ff86b9900afa24eb80ad@localhost> Message-ID: <053.227b7364161cc17ef08a31a535f0b439@localhost> #2310: Panic in ghci 6.8.2 with -fglasgow-exts --------------------+------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the report. Also happens in the HEAD. Here's a smaller example: {{{ $ ghci -XScopedTypeVariables -XPatternSignatures -v0 Prelude> let c = \ x :: a -> (x :: a) ghc-6.9.20080523: panic! (the 'impossible' happened) (GHC version 6.9.20080523 for x86_64-unknown-linux): nameModule a{tv am3} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 26 14:14:46 2008 From: trac at galois.com (GHC) Date: Mon May 26 14:07:51 2008 Subject: [GHC] #2053: Add read_history and write_history bindings to readline In-Reply-To: <042.660e67c9ae82ef2f50c4766a74e43bc8@localhost> References: <042.660e67c9ae82ef2f50c4766a74e43bc8@localhost> Message-ID: <051.0ed9f2fcc246d2bb023747d2fed8540a@localhost> #2053: Add read_history and write_history bindings to readline -------------------------------+-------------------------------------------- Reporter: ajd | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by judah): * status: new => closed * resolution: => fixed Comment: Fixed by: {{{ Mon Jan 21 21:05:36 PST 2008 alexander.dunlap@gmail.com * #2053: add additional history functions The following functions were added: readHistory, writeHistory, appendHistory, historyTruncateFile, clearHistory, stifleHistory, unstifleHistory, historyIsStifled, historyMaxEntries M ./System/Console/Readline.hsc +85 Tue Feb 26 15:39:29 PST 2008 judah.jacobson@gmail.com * #2053: Make readHistory/writeHistory return a Bool instead of throwing an exception on failure. M ./System/Console/Readline.hsc -9 +10 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 26 21:44:17 2008 From: trac at galois.com (GHC) Date: Mon May 26 21:37:24 2008 Subject: [GHC] #2271: floor, ceiling, round :: Double -> Int are awesomely slow In-Reply-To: <043.845265305898c52232b3689d70d3b99c@localhost> References: <043.845265305898c52232b3689d70d3b99c@localhost> Message-ID: <052.c8de166b8e73d1190c1b9b2538f3277e@localhost> #2271: floor, ceiling, round :: Double -> Int are awesomely slow ------------------------------------------+--------------------------------- Reporter: dons | Owner: dons@galois.com Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: performance, math, double | Testcase: Architecture: Unknown | Os: Unknown ------------------------------------------+--------------------------------- Comment (by dons): An old complaint: http://article.gmane.org/gmane.comp.lang.haskell.cafe/21757/ Was due to this issue. The original poster was complaining about: quant8 :: Double -> Word8 quant8 x = floor $ x * 0xFF being too slow. Of course, it turns into a properFraction call, {{{ quant8_rha :: Double -> Word8 quant8_rha = \ (x_ahf :: Double) -> case properFraction5 @ Word8 $f32 (case x_ahf of wild_aVL { D# x1_aVN -> D# (*## x1_aVN 255.0) }) of wild_aUN { (n_aUP, r_aUQ) -> case r_aUQ of wild1_aVn { D# x1_aVp -> case <## x1_aVp 0.0 of wild11_aUS { False -> n_aUP; True -> case n_aUP of wild2_aVx { W8# x#_aVz -> W8# (narrow8Word# (minusWord# x#_aVz __word 1)) } } }}} Rather than an expected unboxed double floor(). The properFraction call there is going to kill things. We'd need a C floor call to get something like: {{{ $wccall_r182 :: Double# -> State# RealWorld -> (# State# RealWorld, Double# #) $wccall_r182 = {__ccall floor Double# -> State# RealWorld -> (# State# RealWorld, Double# #)}_dRy quant8_rha :: Double -> Word8 quant8_rha = \ (x_ahf :: Double) -> case x_ahf of wild_aUI { D# x1_aUK -> case $wccall_r182 (*## x1_aUK 255.0) realWorld# of wild1_XB { (# ds_dRx, ds1_dRw #) -> W8# (narrow8Word# (int2Word# (double2Int# ds1_dRw))) } }}} With the result we can turn this program: {{{ import Data.Word import Data.Array.Vector main = print . sumU . mapU (quant8 :: Double -> Word8) $ enumFromToFracU 0 100000000 }}} From running in 1 minute, 14 seconds, to one that runs in 4.1 seconds. But note, with the pure Haskell quant, we get a fold of this form: {{{ $wfold :: Word# -> Double# -> Word# }}} While with the FFI, we get: {{{ $wfold :: Word# -> Double# -> Word8 }}} Is this related to Neil's issue with FFI and unboxing results? So, anyway, more support that the Double floor/ceiling functions need to be turned into ccalls if we're going to use them for anything with meaningful performance. The full program {{{ {-# LANGUAGE ForeignFunctionInterface #-} import Data.Word import Data.Array.Vector main = print . sumU . mapU (quant8 :: Double -> Word8) $ enumFromToFracU 0 100000000 quant8 :: Double -> Word8 quant8 x = floor' $ x * 0xFF floor' :: Double -> Word8 floor' x = (fromIntegral . (truncate :: Double -> Int)) $ c_floor x foreign import ccall unsafe "math.h floor" c_floor :: Double -> Double }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 27 04:37:28 2008 From: trac at galois.com (GHC) Date: Tue May 27 04:30:39 2008 Subject: [GHC] #2312: object splitting is not done under sparc solaris Message-ID: <045.9cbac76e1c456715b62972e331893bc6@localhost> #2312: object splitting is not done under sparc solaris -----------------------+---------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: sparc | Os: Solaris -----------------------+---------------------------------------------------- I've used gcc-4.2.2 and ghc-6.8.1 to build ghc-6.8.2. For some reason object splitting is not done although for ghc-6.8.1 it worked fine. {{{ -bash-3.00$ ll hello -rwxr-xr-x 1 maeder wimi 3907865 May 23 11:38 hello -bash-3.00$ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","6.8.2") ,("Booter version","6.8.1") ,("Stage","2") ,("Interface file version","6") ,("Have interpreter","YES") ,("Object splitting","YES") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("Win32 DLLs","") ,("RTS ways"," debug thr thr_p thr_debug") ,("Leading underscore","NO") ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 27 04:57:10 2008 From: trac at galois.com (GHC) Date: Tue May 27 04:50:14 2008 Subject: [GHC] #2209: MagicHash extraction is wrong on x86_64 with -fasm -O2 In-Reply-To: <044.b26772684deb839421045da398f72aae@localhost> References: <044.b26772684deb839421045da398f72aae@localhost> Message-ID: <053.a1c69d8d695492b6f74e0e1336a504b0@localhost> #2209: MagicHash extraction is wrong on x86_64 with -fasm -O2 ----------------------+----------------------------------------------------- Reporter: quark | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: Replying to [comment:2 igloo]: > We do claim that this ("Casting an unboxed type to another unboxed type of the same size") works in the `unsafeCoerce#` docs, so we ought to fix it! I'm tempted to alter the docs here. The problem is that the Cmm generated for this program has a type error, which you can see by compiling with `-dcmm-lint`. This breaks some assumptions that the native code generator is making, with the result that it ends up being confused about floating point vs. scalar register assignments. You can achieve the desired effect using castSTUArray, incedentally (this is the way we do it in GHC). To make the direct coercion work, we'd have to make the `unsafeCoerce#` really compile into an operation at the Cmm level. Which is possible, but we'd have to add new primitives for the operation (the current float->int conversions do truncation, not bit-for-bit conversion), and add some code to CoreToStg to generate the operations. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 04:26:06 2008 From: trac at galois.com (GHC) Date: Wed May 28 04:25:36 2008 Subject: [GHC] #2313: libHSrts_thr_debug linked against non-existing bfd library Message-ID: <046.369fe8828ff5a3c111568f185c25c8f0@localhost> #2313: libHSrts_thr_debug linked against non-existing bfd library -------------------------------+-------------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Solaris -------------------------------+-------------------------------------------- It seems there is a bug in RTS somewhere which makes libHSrts_thr_debug in a way it's including some symbols from the bfd library. The bug shows itself as a lot of testsuite tests failing with undefined symbols which originates in the BFD library. Example: =====> cg013(threaded1) cd ./codeGen/should_run && '/buildbot/ghc/kgardas/build/compiler/stage2 /ghc-inplace' -no-recomp -dcore-lint -dcmm-lint -Di386_unknown_solaris2 -o cg013 cg013.hs -threaded -debug >cg013.comp.stderr 2>&1 Compile failed (status 256) errors were: Undefined first referenced symbol in file bfd_openr /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) bfd_init /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) bfd_check_format_matches /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) ld: fatal: Symbol referencing errors. No output written to cg013 collect2: ld returned 1 exit status -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 05:06:08 2008 From: trac at galois.com (GHC) Date: Wed May 28 04:59:08 2008 Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out of range. In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost> References: <044.2f007075e8a3e652be5aa7c77056c714@localhost> Message-ID: <053.f2198cfc6bfa163215aea7954a311bca@localhost> #2013: ghci crash on startup: R_X86_64_32S relocation out of range. ---------------------+------------------------------------------------------ Reporter: mboes | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ---------------------+------------------------------------------------------ Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 05:07:05 2008 From: trac at galois.com (GHC) Date: Wed May 28 05:00:04 2008 Subject: [GHC] #2164: zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd In-Reply-To: <044.65631559df6ce2cd79a1eb038ea82f5f@localhost> References: <044.65631559df6ce2cd79a1eb038ea82f5f@localhost> Message-ID: <053.e82a893a4d3e8a24f94a4c1a15344837@localhost> #2164: zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd ----------------------------+----------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler (FFI) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 05:08:25 2008 From: trac at galois.com (GHC) Date: Wed May 28 05:01:24 2008 Subject: [GHC] #2231: GHC RTS Segfault In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.039efeee021b4393baa95d84d021d2b8@localhost> #2231: GHC RTS Segfault ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 05:15:04 2008 From: trac at galois.com (GHC) Date: Wed May 28 05:08:03 2008 Subject: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 In-Reply-To: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> References: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> Message-ID: <058.9ec928c0c6e0deed879985b75297bffd@localhost> #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 ----------------------------+----------------------------------------------- Reporter: twhitehead | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Comment (by simonmar): Replying to [comment:10 twhitehead]: > With regard to not having a machine with enough memory, I can get you access to our 32GiB-per-node cluster if that would help. Debugging remotely is painful, especially with a bug that takes this long to reproduce. I have a machine with enough memory on order which should arrive in a week or so, which will probably be beyond the 6.8.3 cutoff, unfortunately. If you can send me a binary and a core dump from the failure, I might be able to debug it that way - the assertion failure should produce a core dump, but make sure you have core dumps enabled with "ulimit -c unlimited". On some Linux machines you have to disable the apport service too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 05:38:10 2008 From: trac at galois.com (GHC) Date: Wed May 28 05:31:17 2008 Subject: [GHC] #2312: object splitting is not done under sparc solaris In-Reply-To: <045.9cbac76e1c456715b62972e331893bc6@localhost> References: <045.9cbac76e1c456715b62972e331893bc6@localhost> Message-ID: <054.179aae38da0ab8719dc691c5b564506c@localhost> #2312: object splitting is not done under sparc solaris -----------------------------+---------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: sparc | Os: Solaris -----------------------------+---------------------------------------------- Comment (by maeder): despite -split-objs the output of `ar -t libraries/base/dist/build/libHSbase-3.0.1.0.a` is {{{ PrelIOUtils.o WCsubst.o Win32Utils.o consUtils.o dirUtils.o inputReady.o longlong.o selectUtils.o Concurrent_stub.o Generics__1.o Aliases__1.o Basics__1.o Instances__1.o Schemes__1.o Text__1.o Twins__1.o Concurrent__1.o Arr__1.o Base__1.o Conc__1.o ConsoleHandler__1.o Dotnet__1.o Enum__1.o Environment__1.o Err__1.o Exception__1.o Exts__1.o Float__1.o ForeignPtr__1.o Handle__1.o IO__1.o IOBase__1.o Int__1.o List__1.o Num__1.o PArr__1.o Pack__1.o PrimopWrappers__1.o Ptr__1.o Read__1.o Real__1.o ST__1.o STRef__1.o Show__1.o Stable__1.o Storable__1.o TopHandler__1.o Unicode__1.o Weak__1.o Word__1.o Timeout__1.o Applicative__1.o Arrow__1.o Concurrent__1.o Chan__1.o MVar__1.o QSem__1.o QSemN__1.o SampleVar__1.o Exception__1.o Monad__1.o Fix__1.o Instances__1.o ST__1.o Lazy__1.o Strict__1.o Bits__1.o Bool__1.o Char__1.o Complex__1.o Dynamic__1.o Either__1.o Eq__1.o Fixed__1.o Foldable__1.o Function__1.o HashTable__1.o IORef__1.o Int__1.o Ix__1.o List__1.o Maybe__1.o Monoid__1.o Ord__1.o Ratio__1.o STRef__1.o Lazy__1.o Strict__1.o String__1.o Traversable__1.o Tuple__1.o Typeable__1.o Unique__1.o Version__1.o Word__1.o Trace__1.o Foreign__1.o C__1.o Error__1.o String__1.o Types__1.o ForeignPtr__1.o Marshal__1.o Alloc__1.o Array__1.o Error__1.o Pool__1.o Utils__1.o Ptr__1.o StablePtr__1.o Storable__1.o Numeric__1.o Prelude__1.o GetOpt__1.o CPUTime__1.o Environment__1.o Exit__1.o IO__1.o Error__1.o Unsafe__1.o Info__1.o Mem__1.o StableName__1.o Weak__1.o Internals__1.o Types__1.o ReadP__1.o ReadPrec__1.o Printf__1.o Read__1.o Lex__1.o Show__1.o Functions__1.o Coerce__1.o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 05:49:27 2008 From: trac at galois.com (GHC) Date: Wed May 28 05:42:35 2008 Subject: [GHC] #2312: object splitting is not done under sparc solaris In-Reply-To: <045.9cbac76e1c456715b62972e331893bc6@localhost> References: <045.9cbac76e1c456715b62972e331893bc6@localhost> Message-ID: <054.852a3d7b97699bb3facdc13b706d7bd2@localhost> #2312: object splitting is not done under sparc solaris --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: What build settings are you using, if any? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 05:54:58 2008 From: trac at galois.com (GHC) Date: Wed May 28 05:48:06 2008 Subject: [GHC] #2312: object splitting is not done under sparc solaris In-Reply-To: <045.9cbac76e1c456715b62972e331893bc6@localhost> References: <045.9cbac76e1c456715b62972e331893bc6@localhost> Message-ID: <054.8458ab67fa985cd7e9dca288d56e327d@localhost> #2312: object splitting is not done under sparc solaris --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): I did not explicitly pass `-fvia-C` (or switched off native code generation). my mk/build.mk contains: {{{ BIN_DIST=1 Project=Ghc INSTALL_PROGRAM = $(INSTALL) -s -m 755 XMLDocWays = html HADDOCK_DOCS = YES SRC_HC_OPTS += -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc SplitObjs = YES }}} where `SplitObjs = YES` was omitted initially (without difference). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 05:59:52 2008 From: trac at galois.com (GHC) Date: Wed May 28 05:52:52 2008 Subject: [GHC] #2312: object splitting is not done under sparc solaris In-Reply-To: <045.9cbac76e1c456715b62972e331893bc6@localhost> References: <045.9cbac76e1c456715b62972e331893bc6@localhost> Message-ID: <054.1d078f2b7c351e6fb291d991b2825088@localhost> #2312: object splitting is not done under sparc solaris --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): I may have built the old ghc-6.8.1 with on older gcc version (maybe gcc-4.0.3) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 06:03:10 2008 From: trac at galois.com (GHC) Date: Wed May 28 06:02:31 2008 Subject: [GHC] #2313: libHSrts_thr_debug linked against non-existing bfd library In-Reply-To: <046.369fe8828ff5a3c111568f185c25c8f0@localhost> References: <046.369fe8828ff5a3c111568f185c25c8f0@localhost> Message-ID: <055.a606a24827d0c6fea08ce6e9770b0e2e@localhost> #2313: libHSrts_thr_debug linked against non-existing bfd library -------------------------------+-------------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Solaris -------------------------------+-------------------------------------------- Comment (by kgardas): I've fixed the issue by adding HAVE_LIBBFD ifdef to the RtsConfig.h. I've rerun testsuite and got to 94 unexpected failures from original 521 unexpected failures. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 06:03:20 2008 From: trac at galois.com (GHC) Date: Wed May 28 06:02:38 2008 Subject: [GHC] #2313: libHSrts_thr_debug linked against non-existing bfd library In-Reply-To: <046.369fe8828ff5a3c111568f185c25c8f0@localhost> References: <046.369fe8828ff5a3c111568f185c25c8f0@localhost> Message-ID: <055.46f3a931ee84a80ce92c35ff78752c0a@localhost> #2313: libHSrts_thr_debug linked against non-existing bfd library -------------------------------+-------------------------------------------- Reporter: kgardas | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Solaris -------------------------------+-------------------------------------------- Changes (by kgardas): * owner: kgardas => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 09:34:12 2008 From: trac at galois.com (GHC) Date: Wed May 28 09:27:11 2008 Subject: [GHC] #2209: MagicHash extraction is wrong on x86_64 with -fasm -O2 In-Reply-To: <044.b26772684deb839421045da398f72aae@localhost> References: <044.b26772684deb839421045da398f72aae@localhost> Message-ID: <053.b6020904bd95865c3e9da211bb2011c0@localhost> #2209: MagicHash extraction is wrong on x86_64 with -fasm -O2 ----------------------+----------------------------------------------------- Reporter: quark | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: docs updated. could be merged: {{{ Tue May 27 02:02:44 PDT 2008 Simon Marlow * clarify that unsafeCoerce# :: Float# -> Int# is not safe (see #2209) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 09:34:52 2008 From: trac at galois.com (GHC) Date: Wed May 28 09:27:50 2008 Subject: [GHC] #1959: Recompilation bug In-Reply-To: <047.d023c0f6cd4f6961124bab5854dd4844@localhost> References: <047.d023c0f6cd4f6961124bab5854dd4844@localhost> Message-ID: <056.8e1fe5e4d9515d0ac969fb7e91b676c5@localhost> #1959: Recompilation bug -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: driver/1959 | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Comment (by simonmar): Fixed properly: {{{ Wed May 28 05:52:58 PDT 2008 Simon Marlow * Use MD5 checksums for recompilation checking (fixes #1372, #1959) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 09:35:04 2008 From: trac at galois.com (GHC) Date: Wed May 28 09:28:02 2008 Subject: [GHC] #1959: Recompilation bug In-Reply-To: <047.d023c0f6cd4f6961124bab5854dd4844@localhost> References: <047.d023c0f6cd4f6961124bab5854dd4844@localhost> Message-ID: <056.f8fd541f8f306f988b99d3c188e53b6c@localhost> #1959: Recompilation bug -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: driver/1959 | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 09:40:27 2008 From: trac at galois.com (GHC) Date: Wed May 28 09:33:57 2008 Subject: [GHC] #1372: Recompilation checker should consider package versions (and other factors) In-Reply-To: <047.92f71ee86626c48c755328a887f3d959@localhost> References: <047.92f71ee86626c48c755328a887f3d959@localhost> Message-ID: <056.95383b0268d46416b5a179654de27811@localhost> #1372: Recompilation checker should consider package versions (and other factors) ----------------------+----------------------------------------------------- Reporter: bringert | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed * milestone: 6.8 branch => 6.10 branch Comment: Now fixed (in HEAD, not STABLE, and merging is probably not practical): {{{ Wed May 28 05:52:58 PDT 2008 Simon Marlow * Use MD5 checksums for recompilation checking (fixes #1372, #1959) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 10:00:39 2008 From: trac at galois.com (GHC) Date: Wed May 28 10:00:00 2008 Subject: [GHC] #2308: ghc doesn't honor -keep-tmp-files In-Reply-To: <041.a3c63244dfb916edfa595a2a5f549242@localhost> References: <041.a3c63244dfb916edfa595a2a5f549242@localhost> Message-ID: <050.a4fce2d7f5d7b410462b59c2fb000c3e@localhost> #2308: ghc doesn't honor -keep-tmp-files ----------------------+----------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: minor | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => worksforme Comment: Works for me: {{{ ~/scratch > ghc -keep-tmp-files -c hello.hs -v -cpp Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 3 booted by GHC version 6.8.1 Using package config file: /home/simonmar/fp/lib/x86_64-unknown- linux/ghc-6.8.2/package.conf Using package config file: /home/simonmar/.ghc/x86_64-linux-6.8.2/package.conf hiding package Cabal-1.2.3.0 to avoid conflict with later version Cabal-1.3.3 wired-in package base mapped to base-3.0.1.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package template-haskell mapped to template-haskell-2.2.0.0 wired-in package ndp not found. Hsc static flags: -static Created temporary directory: /tmp/ghc20258_0 *** C pre-processor: gcc -E -undef -traditional -v -I /home/simonmar/fp/lib/x86_64-unknown- linux/ghc-6.8.2/lib/base-3.0.1.0/include -I /home/simonmar/fp/lib/x86_64 -unknown-linux/ghc-6.8.2/include -D__HASKELL1__=5 -D__GLASGOW_HASKELL__=608 -D__HASKELL98__ -D__CONCURRENT_HASKELL__ -Dlinux_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Dlinux_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -x c hello.hs -o /tmp/ghc20258_0/ghc20258_0.hscpp Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable- checking=release --with-system-zlib --enable-__cxa_atexit --disable- libunwind-exceptions --enable-libgcj-multifile --enable- languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1 -E -traditional-cpp -quiet -v -I /home/simonmar/fp/lib/x86_64-unknown- linux/ghc-6.8.2/lib/base-3.0.1.0/include -I /home/simonmar/fp/lib/x86_64 -unknown-linux/ghc-6.8.2/include -D__HASKELL1__=5 -D__GLASGOW_HASKELL__=608 -D__HASKELL98__ -D__CONCURRENT_HASKELL__ -Dlinux_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Dlinux_HOST_OS=1 -Dx86_64_HOST_ARCH=1 hello.hs -o /tmp/ghc20258_0/ghc20258_0.hscpp -mtune=generic -undef ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat- linux/4.1.1/../../../../x86_64-redhat-linux/include" #include "..." search starts here: #include <...> search starts here: /home/simonmar/fp/lib/x86_64-unknown- linux/ghc-6.8.2/lib/base-3.0.1.0/include /home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.8.2/include /usr/local/include /usr/lib/gcc/x86_64-redhat-linux/4.1.1/include /usr/include End of search list. *** Checking old interface for main:Main: *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 10 *** Simplify: Result size = 8 Result size = 8 *** Tidy Core: Result size = 8 *** CorePrep: Result size = 10 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: gcc -I. -c /tmp/ghc20258_0/ghc20258_0.s -o hello.o ~/scratch > ls /tmp/ghc20258_0 ghc20258_0.hscpp ghc20258_0.s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 10:22:15 2008 From: trac at galois.com (GHC) Date: Wed May 28 10:21:34 2008 Subject: [GHC] #2308: ghc doesn't honor -keep-tmp-files In-Reply-To: <041.a3c63244dfb916edfa595a2a5f549242@localhost> References: <041.a3c63244dfb916edfa595a2a5f549242@localhost> Message-ID: <050.8e0a02a5a5ceb64997cd015f006ada82@localhost> #2308: ghc doesn't honor -keep-tmp-files ----------------------+----------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: minor | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by igloo): It doesn't work in 6.6.1, but that branch is long-dead, I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 11:16:20 2008 From: trac at galois.com (GHC) Date: Wed May 28 11:09:21 2008 Subject: [GHC] #2164: zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd In-Reply-To: <044.65631559df6ce2cd79a1eb038ea82f5f@localhost> References: <044.65631559df6ce2cd79a1eb038ea82f5f@localhost> Message-ID: <053.476eb7c62a92cb98034d184b308ba739@localhost> #2164: zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd ----------------------------+----------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.8.3 Component: Compiler (FFI) | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Wed May 28 07:39:37 BST 2008 Simon Marlow * FIX #2164: check for ThreadRelocated in isAlive() }}} I committed this to STABLE only for now, because I don't want to conflict with my parallel GC branch where I've made the equivalent fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 11:20:24 2008 From: trac at galois.com (GHC) Date: Wed May 28 11:13:27 2008 Subject: [GHC] #631: GHCi doesn't work unregisterised In-Reply-To: <058.77987f0da5513fbc618ea4c0e4ce6de9@localhost> References: <058.77987f0da5513fbc618ea4c0e4ce6de9@localhost> Message-ID: <067.082f8a617140ff72af7a3f3924131ddf@localhost> #631: GHCi doesn't work unregisterised ---------------------------------+------------------------------------------ Reporter: trentbuck@gmail.com | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.4.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.8 branch => 6.10 branch Comment: In theory this should be working now (libffi was imported). In practice, the tests appear to be failing in the unreg nightly build, so I need to figure out what's going on there. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 11:44:09 2008 From: trac at galois.com (GHC) Date: Wed May 28 11:37:09 2008 Subject: [GHC] #2277: GHCi silently aborts on 'take' computation In-Reply-To: <046.02df5e44a831fb20777998dee9adae29@localhost> References: <046.02df5e44a831fb20777998dee9adae29@localhost> Message-ID: <055.f713d94a979a5577290c624801c6568f@localhost> #2277: GHCi silently aborts on 'take' computation ---------------------+------------------------------------------------------ Reporter: cdsmith | Owner: Type: bug | Status: reopened Priority: high | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Changes (by simonmar): * priority: normal => high * severity: normal => blocker Comment: I see this too: {{{ 18303 ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = -1 EINT R (Interrupted system call) 18303 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- 18303 rt_sigreturn(0x1a) = -1 EINTR (Interrupted system call) }}} followed quickly by GHCi exiting. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 16:24:23 2008 From: trac at galois.com (GHC) Date: Wed May 28 16:17:21 2008 Subject: [GHC] #2314: GHC 6.8.3 release candidate fails to build under glibc 2.8.0 Message-ID: <044.f13ab1b463426d780a18b6d4673b09a7@localhost> #2314: GHC 6.8.3 release candidate fails to build under glibc 2.8.0 -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: blocker Keywords: | Testcase: Architecture: Multiple | Os: Linux -------------------------+-------------------------------------------------- In glibc 2.8.0, the "struct ucred" structure has been hidden by default, and the network package must be compiled with -D_GNU_SOURCE to make it visible. This affects both GHC 6.8.2 and the current 6.8.3 snapshot. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 28 16:27:54 2008 From: trac at galois.com (GHC) Date: Wed May 28 16:20:52 2008 Subject: [GHC] #2314: GHC 6.8.3 release candidate fails to build under glibc 2.8.0 In-Reply-To: <044.f13ab1b463426d780a18b6d4673b09a7@localhost> References: <044.f13ab1b463426d780a18b6d4673b09a7@localhost> Message-ID: <053.a561a1c31fe8d6d974a36414fa6db66e@localhost> #2314: GHC 6.8.3 release candidate fails to build under glibc 2.8.0 -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Linux -------------------------+-------------------------------------------------- Comment (by bos): I'm the reporter and author of the patch, by the way. Current Linux distros affected by this problem include Fedora 9 and Ubuntu 8.04, both of which are the most recent releases in their respective lines. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 29 00:11:59 2008 From: trac at galois.com (GHC) Date: Thu May 29 00:04:55 2008 Subject: [GHC] #2315: Control.Applicative.ZipList doesn't derive Show Message-ID: <046.585e46ba5f67d2dd3e60b3824a844b5a@localhost> #2315: Control.Applicative.ZipList doesn't derive Show -------------------------+-------------------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- The Control.Applicative.ZipList type is not an instance of Show. To reproduce show $ ZipList [1,2,3] which gives an error: add an instance declaration for (Show (ZipList t)) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 29 00:41:03 2008 From: trac at galois.com (GHC) Date: Thu May 29 00:34:00 2008 Subject: [GHC] #2316: Add Applicative instances for all MTL Monads Message-ID: <047.6c77bc0cfe5b195806e995b0a81d8474@localhost> #2316: Add Applicative instances for all MTL Monads -------------------------+-------------------------------------------------- Reporter: sjanssen | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- This is a proposal to add Applicative instances corresponding to each Monad instance in the MTL. Note that mtl will now depend on base >= 2.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 29 00:54:04 2008 From: trac at galois.com (GHC) Date: Thu May 29 00:47:01 2008 Subject: [GHC] #2317: Garbage collector crashes in simple parallel sorting program Message-ID: <042.8ee6ef408a3ac33a390a9401d994a2b4@localhost> #2317: Garbage collector crashes in simple parallel sorting program -------------------------+-------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: Multiple | Os: Linux -------------------------+-------------------------------------------------- I have a very simple parallel program that crashes quite reproducibly. On x86-64 and x86-32, the symptoms are subtly different, but equally catastrophic. x86-64: {{{$ ghc -threaded -O2 --make -o Sorting Sorting [1 of 1] Compiling Main ( Sorting.hs, Sorting.o ) Linking Sorting ... $ ./Sorting +RTS -N2 -RTS 100000 100000 Segmentation fault}}} x86-32: {{{$ ghc -O2 --make -threaded -o Sorting Sorting [1 of 1] Compiling Main ( Sorting.hs, Sorting.o ) Linking Sorting ... $ ./Sorting +RTS -N2 -RTS 125000 125000 Sorting: internal error: evacuate: strange closure type 17805 (GHC version 6.8.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted}}} Here's a somewhat useless backtrace from gdb on x86-64: {{{#1 0x00007fb49eac2d83 in abort () at abort.c:88 #2 0x0000000000444c45 in rtsFatalInternalErrorFn () #3 0x0000000000444efc in barf () #4 0x0000000000464c9c in evacuate () #5 0x000000000044d213 in scavenge_stack () #6 0x000000000044e4ba in scavenge_one () #7 0x000000000044e8d6 in scavenge_mutable_list () #8 0x000000000044bc49 in GarbageCollect () #9 0x0000000000445d1f in scheduleDoGC () #10 0x0000000000446ff8 in schedule () #11 0x0000000000447339 in workerStart () #12 0x0000000000f6c29a in start_thread (arg=) at pthread_create.c:297 #13 0x00007fb49eb732cd in clone () from /lib64/libc.so.6}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 29 01:06:50 2008 From: trac at galois.com (GHC) Date: Thu May 29 00:59:45 2008 Subject: [GHC] #2317: Garbage collector crashes in simple parallel sorting program In-Reply-To: <042.8ee6ef408a3ac33a390a9401d994a2b4@localhost> References: <042.8ee6ef408a3ac33a390a9401d994a2b4@localhost> Message-ID: <051.9acdeb220e3906dccbbdb5856cc6105b@localhost> #2317: Garbage collector crashes in simple parallel sorting program -------------------------------+-------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Linux -------------------------------+-------------------------------------------- Comment (by bos): Actually, on x86-64, the program crashes about 90% of the time, not always. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 29 03:59:29 2008 From: trac at galois.com (GHC) Date: Thu May 29 03:52:25 2008 Subject: [GHC] #2317: Garbage collector crashes in simple parallel sorting program In-Reply-To: <042.8ee6ef408a3ac33a390a9401d994a2b4@localhost> References: <042.8ee6ef408a3ac33a390a9401d994a2b4@localhost> Message-ID: <051.9d45f02b45ac3b65837e1c8057aa36ab@localhost> #2317: Garbage collector crashes in simple parallel sorting program ----------------------------+----------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.8.3 Old description: > I have a very simple parallel program that crashes quite reproducibly. > On x86-64 and x86-32, the symptoms are subtly different, but equally > catastrophic. > > x86-64: > > {{{$ ghc -threaded -O2 --make -o Sorting Sorting > [1 of 1] Compiling Main ( Sorting.hs, Sorting.o ) > Linking Sorting ... > $ ./Sorting +RTS -N2 -RTS 100000 > 100000 > Segmentation fault}}} > > x86-32: > > {{{$ ghc -O2 --make -threaded -o Sorting Sorting > [1 of 1] Compiling Main ( Sorting.hs, Sorting.o ) > Linking Sorting ... > $ ./Sorting +RTS -N2 -RTS 125000 > 125000 > Sorting: internal error: evacuate: strange closure type 17805 > (GHC version 6.8.2 for i386_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Aborted}}} > > Here's a somewhat useless backtrace from gdb on x86-64: > > {{{#1 0x00007fb49eac2d83 in abort () at abort.c:88 > #2 0x0000000000444c45 in rtsFatalInternalErrorFn () > #3 0x0000000000444efc in barf () > #4 0x0000000000464c9c in evacuate () > #5 0x000000000044d213 in scavenge_stack () > #6 0x000000000044e4ba in scavenge_one () > #7 0x000000000044e8d6 in scavenge_mutable_list () > #8 0x000000000044bc49 in GarbageCollect () > #9 0x0000000000445d1f in scheduleDoGC () > #10 0x0000000000446ff8 in schedule () > #11 0x0000000000447339 in workerStart () > #12 0x0000000000f6c29a in start_thread (arg=) > at pthread_create.c:297 > #13 0x00007fb49eb732cd in clone () from /lib64/libc.so.6}}} New description: I have a very simple parallel program that crashes quite reproducibly. On x86-64 and x86-32, the symptoms are subtly different, but equally catastrophic. x86-64: {{{ $ ghc -threaded -O2 --make -o Sorting Sorting [1 of 1] Compiling Main ( Sorting.hs, Sorting.o ) Linking Sorting ... $ ./Sorting +RTS -N2 -RTS 100000 100000 Segmentation fault }}} x86-32: {{{ $ ghc -O2 --make -threaded -o Sorting Sorting [1 of 1] Compiling Main ( Sorting.hs, Sorting.o ) Linking Sorting ... $ ./Sorting +RTS -N2 -RTS 125000 125000 Sorting: internal error: evacuate: strange closure type 17805 (GHC version 6.8.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} Here's a somewhat useless backtrace from gdb on x86-64: {{{ #1 0x00007fb49eac2d83 in abort () at abort.c:88 #2 0x0000000000444c45 in rtsFatalInternalErrorFn () #3 0x0000000000444efc in barf () #4 0x0000000000464c9c in evacuate () #5 0x000000000044d213 in scavenge_stack () #6 0x000000000044e4ba in scavenge_one () #7 0x000000000044e8d6 in scavenge_mutable_list () #8 0x000000000044bc49 in GarbageCollect () #9 0x0000000000445d1f in scheduleDoGC () #10 0x0000000000446ff8 in schedule () #11 0x0000000000447339 in workerStart () #12 0x0000000000f6c29a in start_thread (arg=) at pthread_create.c:297 #13 0x00007fb49eb732cd in clone () from /lib64/libc.so.6 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 29 03:59:43 2008 From: trac at galois.com (GHC) Date: Thu May 29 03:52:41 2008 Subject: [GHC] #2317: Garbage collector crashes in simple parallel sorting program In-Reply-To: <042.8ee6ef408a3ac33a390a9401d994a2b4@localhost> References: <042.8ee6ef408a3ac33a390a9401d994a2b4@localhost> Message-ID: <051.6c9bbf0f05cdbd5e119d5f3c26da58fb@localhost> #2317: Garbage collector crashes in simple parallel sorting program ----------------------------+----------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 29 04:53:25 2008 From: trac at galois.com (GHC) Date: Thu May 29 04:46:21 2008 Subject: [GHC] #2317: Garbage collector crashes in simple parallel sorting program In-Reply-To: <042.8ee6ef408a3ac33a390a9401d994a2b4@localhost> References: <042.8ee6ef408a3ac33a390a9401d994a2b4@localhost> Message-ID: <051.57518a59acb8b940ab5f1afe87cabfae@localhost> #2317: Garbage collector crashes in simple parallel sorting program ----------------------------+----------------------------------------------- Reporter: bos | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: major | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: I can't repeat it with the latest STABLE branch; suspected dup of #2192 which is already fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 29 07:31:12 2008 From: trac at galois.com (GHC) Date: Thu May 29 07:24:13 2008 Subject: [GHC] #1970: ghci -hide-all-packages gives bad error message In-Reply-To: <046.46e655a12ebdc87b2836ef76c030a7e8@localhost> References: <046.46e655a12ebdc87b2836ef76c030a7e8@localhost> Message-ID: <055.0a8a12fa5e4f891496b18bcbeb93e0ea@localhost> #1970: ghci -hide-all-packages gives bad error message ---------------------+------------------------------------------------------ Reporter: dfranke | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.8.1 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: Fixed: {{{ Wed May 28 16:45:28 BST 2008 Simon Marlow * FIX #1970: ghci -hide-all-packages should work }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 29 07:33:18 2008 From: trac at galois.com (GHC) Date: Thu May 29 07:26:13 2008 Subject: [GHC] #1956: panic on runhaskell Setup configure on base In-Reply-To: <051.ef75b234a372362002a1e8acca106578@localhost> References: <051.ef75b234a372362002a1e8acca106578@localhost> Message-ID: <060.5516dee66307cecd61b3406c70319527@localhost> #1956: panic on runhaskell Setup configure on base --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | --------------------------+------------------------------------------------- Changes (by simonmar): * status: new => closed * type: bug => merge * resolution: => fixed Comment: Fixed by this: {{{ Wed May 28 16:45:28 BST 2008 Simon Marlow * FIX #1970: ghci -hide-all-packages should work }}} although note that you need to use `-i`: {{{ runhaskell -i Setup.hs configure }}} otherwise GHC thinks `Prelude` means `./Prelude.hs` which isn't built. -- Ticket URL: GHC The Glasgow Haskell Compiler From mechvel at botik.ru Thu May 29 08:21:13 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu May 29 08:14:15 2008 Subject: SCC "ab cd" Message-ID: <20080529122113.GA18946@scico.botik.ru> Dear GHC developers, ghc-6.8.2 compiles {-# SCC "ab cd" #-} as all right. And the GHC candidate of May 27, 2008 reports the error: "spaces are not allowed in SCC". Do you think that this latter has more sense? Is not this a matter of the programmer to give string names to SCC points? Regards, ----------------- Serge Mechveliani mechvel@botik.ru From trac at galois.com Thu May 29 08:56:24 2008 From: trac at galois.com (GHC) Date: Thu May 29 08:49:24 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails Message-ID: <045.009b69f25f0ac7df34c06021735a7f36@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails -----------------------+---------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Solaris -----------------------+---------------------------------------------------- {{{ ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict- prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc- Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc- Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I../gmp/gmpbuild -optc-fno-strict-aliasing -optc-w -H16m -O -optc-O2 -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -c Typeable.c -o Typeable.o In file included from /usr/include/sys/int_types.h:34, from /usr/include/sys/stdint.h:17, from /usr/include/stdint.h:17, from ../includes/HsFFI.h:31, from ../includes/RtsAPI.h:16, from ../includes/RtsExternal.h:13, from ../includes/Stg.h:177, from ../includes/RtsTypeable.h:12, from Typeable.c:9:0: /export/local1/mirror/lang/bin/../lib/gcc/i386-pc- solaris2.10/4.2.2/include/sys/feature_tests.h:345:2: error: #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications require the use of c99" gmake[1]: *** [Typeable.o] Error 1 gmake: *** [stage1] Error 1 }}} using gcc-4.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From isaacdupree at charter.net Thu May 29 09:07:32 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu May 29 09:00:28 2008 Subject: SCC "ab cd" In-Reply-To: <20080529122113.GA18946@scico.botik.ru> References: <20080529122113.GA18946@scico.botik.ru> Message-ID: <483EAA94.6000203@charter.net> Serge D. Mechveliani wrote: > Dear GHC developers, > > ghc-6.8.2 compiles {-# SCC "ab cd" #-} as all right. > > And the GHC candidate of May 27, 2008 reports the error: > > "spaces are not allowed in SCC". > > Do you think that this latter has more sense? > Is not this a matter of the programmer to give string names to SCC > points? see http://hackage.haskell.org/trac/ghc/ticket/2071 . Agree or disagree. "it probably never worked" -- Did you ever get any useful profiling information when you had spaces in your SCC? Or did it just not work anyway (in which case a sooner error message is probably better) -Isaac From mechvel at botik.ru Thu May 29 09:13:11 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu May 29 09:06:04 2008 Subject: bug in "may27" candidate Message-ID: <20080529131311.GA19502@scico.botik.ru> In addition to the bug report of DoCon-2.11: making docon with -Onot is fast enough, but running the test shows the same error as with -O. ----------- Mechveliani From trac at galois.com Thu May 29 09:37:44 2008 From: trac at galois.com (GHC) Date: Thu May 29 09:30:38 2008 Subject: [GHC] #2319: STM not as fair as it could be Message-ID: <044.81823a3e2ec18990aac9bedd6527630b@localhost> #2319: STM not as fair as it could be -------------------------+-------------------------------------------------- Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- Even though this has been discussed via email I'm filing a ticket so that the issue and the patch aren't forgotten about. If the patch is accepted it would be nice if it could be included in 6.8.3 provided it merges cleanly. GHC's STM implementation could be a bit more fair. Suppose you have several transactions waiting for a variable to be updated. When that variable is updated all transactions are woken up. The problem is that the transaction which was blocked last is woken up first. This leads to unnecessary starvation in some programs. There is a patch which fixes this. It can be downloaded from here: http://www.haskell.org/pipermail/cvs-ghc/2008-April/041943.html -- Ticket URL: GHC The Glasgow Haskell Compiler From marlowsd at gmail.com Thu May 29 10:17:36 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 29 10:10:34 2008 Subject: [Haskell-cafe] Bug in parallel GHC runtime? In-Reply-To: <20080523183348.GE4034@scytale.galois.com> References: <4836DAAF.7090701@fit.vutbr.cz> <20080523183348.GE4034@scytale.galois.com> Message-ID: <483EBB00.2050203@gmail.com> Don Stewart wrote: > Hi, > > Thanks for the bug report. > This should be filed on the GHC bug tracker, > > http://hackage.haskell.org/trac/ghc/newticket?type=bug > > And I've forwarded it to the glasgow-haskell-bugs mailing list. Please try with the 6.8.3 RC we just released. I fixed a bug that could be the cause of this. http://www.haskell.org/pipermail/glasgow-haskell-users/2008-May/014814.html Cheers, Simon > > kolar: >> Hello all, >> >> The attached file was compiled by the following command: >> >> ghc -O2 --make -threaded ltest1pl.hs -o alall >> >> When run in a sequential mode, I get this result: >> ./alall >> Starting ... >> Lst1: 41666666650000 >> Lst2: 41669166700000 >> T1: 0m 1.0e-6s >> 36 >> End! >> >> >> On the other hand, when run in a threaded mode, I get the following error: >> ./alall +RTS -N2 >> Starting ... >> Lst1: 41666666650000 >> Lst2: 41669166700000 >> T1: 0m 0.0s >> Segmentation fault >> >> Is it fault of the GHC runtime, or is it something on my side? >> >> >> My machine: uname -a >> Linux pc 2.6.24-ARCH #1 SMP PREEMPT Sun Mar 30 10:50:22 CEST 2008 x86_64 >> Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux >> >> My ghc: ghc --version >> The Glorious Glasgow Haskell Compilation System, version 6.8.2 >> >> >> Thanks and regards >> Dusan >> > >> --import Control.Concurrent >> --import Control.Concurrent.MVar >> import System.Time >> >> import Control.Parallel.Strategies >> >> --import Data.List (foldl') >> import qualified Data.ByteString as B >> >> >> sumAllSums [] = 0 >> sumAllSums l@(_:xs) = sumlist 0 l + sumAllSums xs >> where sumlist res [] = res >> sumlist sr (v:vs) = sumlist (sr+v) vs >> >> wlist2wbs [] = B.pack [] >> wlist2wbs l@(_:_) = B.pack $ encode l >> where >> encode :: Integral a => [Int] -> [a] >> encode [] = [] >> encode (x:xs) = >> if x==0 then 0:0:encode xs >> else fromIntegral (x `mod` 256) : fromIntegral (x `div` 256) : encode xs >> >> main = do >> putStrLn $ "Starting ..." >> let lst1 = [0..49999] >> let lst2 = [0..50000] >> let bs1 = wlist2wbs lst1 >> let bs2 = wlist2wbs lst2 >> tm1 <- getClockTime >> let (v1:v2:_) = parMap rnf sumAllSums [lst1,lst2] >> tm1' <- getClockTime >> putStrLn ("Lst1: " ++ show v1) >> putStrLn ("Lst2: " ++ show v2) >> let tdiff1 = diffClockTimes tm1' tm1 >> --let tdiff2 = diffClockTimes tm2' tm2 >> putStrLn $ "T1: " ++ show (tdMin tdiff1) ++ "m " ++ show (fromIntegral(tdSec tdiff1) + fromIntegral(tdPicosec tdiff1)/1e12) ++ "s" >> --putStrLn $ "T2: " ++ show (tdMin tdiff2) ++ "m " ++ show (fromIntegral(tdSec tdiff2) + fromIntegral(tdPicosec tdiff2)/1e12) ++ "s" >> putStrLn $ show $ {-ibs1 +-} B.index bs1 99999 + B.index bs2 49999 {-((bs1 + fromIntegral (B.index bs2 99999)) :: Integer)-} >> putStrLn $ "End!" >> >> {- >> main = do >> tm1 <- getClockTime >> putStrLn $ "Starting ... " >> mv1 <- newEmptyMVar >> mv2 <- newEmptyMVar >> t1 <- forkIO (putMVar mv1 $! sumAllSums [0..49999]) >> t2 <- forkIO (putMVar mv2 $! sumAllSums [1..50000]) >> v1 <- takeMVar mv1 >> v2 <- takeMVar mv2 >> killThread t1 >> killThread t2 >> putStrLn $ "Result: " ++ show (v1+v2) >> tm2 <- getClockTime >> let tdiff = diffClockTimes tm2 tm1 >> putStrLn $ "End! " ++ show (tdMin tdiff) ++ "m " ++ show (fromIntegral(tdSec tdiff) + fromIntegral(tdPicosec tdiff)/1e12) ++ "s" >> -} >> > >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu May 29 12:22:29 2008 From: trac at galois.com (GHC) Date: Thu May 29 12:15:23 2008 Subject: [GHC] #2320: Rename RecordPuns extension to NamedFieldPuns Message-ID: <045.fc02c8cc0d5ca1cd2c053631b5107d39@localhost> #2320: Rename RecordPuns extension to NamedFieldPuns ------------------------+--------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- The `NamedFieldPuns` has been around for ages. It's in the original Cabal design spec in the extension list. It was implemented in nhc98 for yonks (with the flag `-puns`). In older ghc it was enables with `-frecord-puns`. In ghc-6.8 we split up the `-fglasgow-exts` flag into lots of separate named extensions. We added an extension `RecordPuns` for the thing that `-frecord-puns` had enabled previously not realising that there was already an older name for the same thing, namely `NamedFieldPuns`. So I propose that ghc moves to using the standard extension `NamedFieldPuns` and keeps `RecordPuns` as a deprecated alias for `NamedFieldPuns`. Cabal can fix things up so that for ghc-6.8 it maps the `NamedFieldPuns` extension to `-frecord-puns` or `-XRecordPuns`. The moral of the story here is that all the extensions in Language.Haskell.Extensions should be well documented in that module. For one thing that'd serve as a useful reference for users, but also for compiler hackers to pick consistent names for the same concepts between implementations. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 30 04:04:42 2008 From: trac at galois.com (GHC) Date: Fri May 30 03:57:45 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.e3bdec861d0f5139dbb1d05b19020707@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 30 05:19:48 2008 From: trac at galois.com (GHC) Date: Fri May 30 05:12:42 2008 Subject: [GHC] #2321: Static argument transformation is causing a core-lint failure on GHC.PrimopWrappers Message-ID: <047.16506ecd0cf212b2924a7b72867eeece@localhost> #2321: Static argument transformation is causing a core-lint failure on GHC.PrimopWrappers -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- The new SAT transformation is causing this failure in the nightly builds when compiling the `ghc-prim` package with `-O2 -dcore-lint`: {{{ /64playpen/buildbot/x86_64-linux-head/build/compiler/stage1/ghc-inplace -package-name ghc-prim-0.1 -hide-all-packages -split-objs -i -idist/build -i. -idist/build/autogen -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build -O -package-name ghc-prim -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -idist/build -H32m -O -O2 -fasm -dcore-lint -fgenerics -c GHC/PrimopWrappers.hs -o dist/build/GHC/PrimopWrappers.o -ohi dist/build/GHC/PrimopWrappers.hi *** Core Lint Errors: in result of Static argument *** : [RHS of $sat_s3dL :: (# GHC.Prim.State# d_a15v, GHC.Prim.MutableArray# d_a15v a_a15u #)] A variable has unboxed tuple type: $sat_s3dL Binder's type: (# GHC.Prim.State# d_a15v, GHC.Prim.MutableArray# d_a15v a_a15u #) *** Offending Program *** }}} I will disable SAT for now until this is fixed. Also, SAT appears to be run directly after the desugarer and before any simplification at all, which is probably suboptimal (e.g. lots of non- recursive functions will be marked as recursive). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 30 07:17:46 2008 From: trac at galois.com (GHC) Date: Fri May 30 07:10:38 2008 Subject: [GHC] #2322: cmath library broken with -fvia-C Message-ID: <047.4f5ed74e9c0974e832a64d783dd3e20d@localhost> #2322: cmath library broken with -fvia-C -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- The cmath library cannot be built with 6.9.x using `-fvia-C` because it calls functions from `math.h`. Although we'll probably only be supporting unregisterised `-fvia-C` in 6.10, we should still fix this. See [http://www.haskell.org/pipermail/cvs-libraries/2008-May/008816.html]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 30 09:02:48 2008 From: trac at galois.com (GHC) Date: Fri May 30 08:55:40 2008 Subject: [GHC] #2323: Segfaulting binary only with modules Message-ID: <043.59108a38ad3f698b1c3d8890dcfb5bc4@localhost> #2323: Segfaulting binary only with modules ------------------------+--------------------------------------------------- Reporter: yrn1 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: powerpc | Os: MacOS X ------------------------+--------------------------------------------------- tgz with 2 files attached: Math.hs and Main.hs. Math.hs contains some utility functions and Main.hs uses them. When compiling this (ghc --make Main) and running ./Main, it segfaults. But when putting everything from Math.hs in Main.hs (and hence eliminating the Math module) and compiling again, it does not segfault. Note removing that the PRAGMA's in the Math.hs file does not change this behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 30 09:50:40 2008 From: trac at galois.com (GHC) Date: Fri May 30 09:43:40 2008 Subject: [GHC] #2312: object splitting is not done under sparc solaris In-Reply-To: <045.9cbac76e1c456715b62972e331893bc6@localhost> References: <045.9cbac76e1c456715b62972e331893bc6@localhost> Message-ID: <054.6d09aee5ee03352342392000bcc7a650@localhost> #2312: object splitting is not done under sparc solaris --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): object splitting works with gcc-3.4.4 (I'll attach tmp files). I've called {{{ ghc --make -no-recomp -split-objs -optc-mcpu=ultrasparc -opta- mcpu=ultrasparc -keep-tmp-files HughesPJ.hs }}} Without the ultrasparc opts gcc-3.4.4 complained about `Architecture mismatch` {{{ (Requires v9|v9a|v9b; requested architecture is v8.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 30 10:12:10 2008 From: trac at galois.com (GHC) Date: Fri May 30 10:05:03 2008 Subject: [GHC] #2262: Build failure of HEAD from 2008-05-04 on OS X 10.4.11 In-Reply-To: <047.3f0e3b88d9818643a9caa58f0fc62bf1@localhost> References: <047.3f0e3b88d9818643a9caa58f0fc62bf1@localhost> Message-ID: <056.058a68a43f77eabc1017359e5bb327f2@localhost> #2262: Build failure of HEAD from 2008-05-04 on OS X 10.4.11 -------------------------+-------------------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Comment (by nominolo): The current workaround is to comment out this line in {{{rts/Makefile}}}: {{{ SRC_HC_OPTS += -fvia-C }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 30 10:13:41 2008 From: trac at galois.com (GHC) Date: Fri May 30 10:06:32 2008 Subject: [GHC] #2320: Rename RecordPuns extension to NamedFieldPuns In-Reply-To: <045.fc02c8cc0d5ca1cd2c053631b5107d39@localhost> References: <045.fc02c8cc0d5ca1cd2c053631b5107d39@localhost> Message-ID: <054.ba9991f4bb14e6f1ac0d16015a6da9bc@localhost> #2320: Rename RecordPuns extension to NamedFieldPuns ----------------------+----------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Sorry I didn't notice that when I added `-XRecordPuns`. Its a pity it made it into 6.8! Let's do as you suggest for 6.10. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 31 04:32:53 2008 From: trac at galois.com (GHC) Date: Sat May 31 04:25:43 2008 Subject: [GHC] #2324: Data.Tree.Zipper in containers package Message-ID: <049.73ff21dd84d1ae329478d35cb5f6f5ed@localhost> #2324: Data.Tree.Zipper in containers package --------------------------------+------------------------------------------- Reporter: kr.angelov | Owner: kr.angelov Type: feature request | Status: new Priority: normal | Component: libraries (other) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- The proposal is to add Data.Tree.Zipper implementation in the containers package. The current implementation with QuickCheck properties is attached. The dead line for considerations is one week after the ticket submissions. -- Ticket URL: GHC The Glasgow Haskell Compiler From mechvel at botik.ru Sat May 31 04:54:50 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat May 31 04:47:42 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080529141006.GA12898@matrix.chaos.earth.li> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20080528182858.GA16929@scico.botik.ru> <20080529094440.GA415@matrix.chaos.earth.li> <20080529114836.GA18601@scico.botik.ru> <20080529141006.GA12898@matrix.chaos.earth.li> Message-ID: <20080531085450.GA628@scico.botik.ru> This is a bug report for the ghc candidate of May 27, 2008 for ghc-6.8.3. A short program example for this bug candidate is on http://botik.ru/pub/local/Mechveliani/ghcBugs/candidateMay27-08-bug.zip Unzip and follow install.txt. The example is made by reducing DoCon-2.11. Regards, ----------------- Serge Mechveliani mechvel@botik.ru On Thu, May 29, 2008 at 03:10:07PM +0100, Ian Lynagh wrote: > On Thu, May 29, 2008 at 03:48:36PM +0400, Serge D. Mechveliani wrote: > > > > Main: fromInteger to (Pol ..): use fromi > > OK, I can reproduce this, but as we aren't familiar with the code, it > would be very helpful if you could make a small case demonstrating the > problem (i.e. something that doesn't depend on the huge docon library). From trac at galois.com Sat May 31 08:25:46 2008 From: trac at galois.com (GHC) Date: Sat May 31 08:18:36 2008 Subject: [GHC] #2314: GHC 6.8.3 release candidate fails to build under glibc 2.8.0 In-Reply-To: <044.f13ab1b463426d780a18b6d4673b09a7@localhost> References: <044.f13ab1b463426d780a18b6d4673b09a7@localhost> Message-ID: <053.1b162f5b15a83064cec2963915575532@localhost> #2314: GHC 6.8.3 release candidate fails to build under glibc 2.8.0 -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.8.3 Component: libraries/network | Version: 6.8.2 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Patch applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From dons at galois.com Sat May 31 13:15:51 2008 From: dons at galois.com (Don Stewart) Date: Sat May 31 13:09:00 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080531085450.GA628@scico.botik.ru> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20080528182858.GA16929@scico.botik.ru> <20080529094440.GA415@matrix.chaos.earth.li> <20080529114836.GA18601@scico.botik.ru> <20080529141006.GA12898@matrix.chaos.earth.li> <20080531085450.GA628@scico.botik.ru> Message-ID: <20080531171551.GC32271@scytale.galois.com> Hi Serge, Can you add it to our bug tracker, so this bug report is not lost? http://hackage.haskell.org/trac/ghc/newticket?type=bug -- Don mechvel: > This is a bug report for the ghc candidate of May 27, 2008 > for ghc-6.8.3. > A short program example for this bug candidate is on > > http://botik.ru/pub/local/Mechveliani/ghcBugs/candidateMay27-08-bug.zip > > Unzip and follow install.txt. > The example is made by reducing DoCon-2.11. > > Regards, > > ----------------- > Serge Mechveliani > mechvel@botik.ru > > > > On Thu, May 29, 2008 at 03:10:07PM +0100, Ian Lynagh wrote: > > On Thu, May 29, 2008 at 03:48:36PM +0400, Serge D. Mechveliani wrote: > > > > > > Main: fromInteger to (Pol ..): use fromi > > > > OK, I can reproduce this, but as we aren't familiar with the code, it > > would be very helpful if you could make a small case demonstrating the > > problem (i.e. something that doesn't depend on the huge docon library). > > > > > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Sat May 31 14:26:01 2008 From: trac at galois.com (GHC) Date: Sat May 31 14:18:49 2008 Subject: [GHC] #2325: Compile-time computations Message-ID: <042.ec8f910033c06987836e7597539e54db@localhost> #2325: Compile-time computations -----------------------------------------+---------------------------------- Reporter: ajd | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- {{{ $ cat Reduce3.hs module Reduce3 where foo = 1 + 2 $ cat Reduce4.hs module Reduce4 where foo = 3 $ ghc -c -O2 -fforce-recomp -ddump-simpl Reduce3.hs ==================== Tidy Core ==================== Reduce3.lvl :: GHC.Num.Integer [GlobalId] [NoCafRefs] Reduce3.lvl = GHC.Num.S# 1 Reduce3.lvl1 :: GHC.Num.Integer [GlobalId] [NoCafRefs] Reduce3.lvl1 = GHC.Num.S# 2 Reduce3.foo :: GHC.Num.Integer [GlobalId] [Str: DmdType] Reduce3.foo = GHC.Num.plusInteger Reduce3.lvl Reduce3.lvl1 ==================== Tidy Core Rules ==================== $ ghc -c -O2 -fforce-recomp -ddump-simpl Reduce4.hs ==================== Tidy Core ==================== Reduce4.foo :: GHC.Num.Integer [GlobalId] [NoCafRefs Str: DmdType] Reduce4.foo = GHC.Num.S# 3 ==================== Tidy Core Rules ==================== }}} It would be nice if GHC could do the addition at compile time (since, after all, the result will always be the same) instead of at runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 31 14:34:35 2008 From: trac at galois.com (GHC) Date: Sat May 31 14:27:23 2008 Subject: [GHC] #2325: Compile-time computations In-Reply-To: <042.ec8f910033c06987836e7597539e54db@localhost> References: <042.ec8f910033c06987836e7597539e54db@localhost> Message-ID: <051.b45e5d0f4a04a954d10fba5689758a92@localhost> #2325: Compile-time computations -----------------------------------------+---------------------------------- Reporter: ajd | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: constant folding | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- Changes (by dons): * keywords: => constant folding Comment: I think this is specific to Integer, which is a more complex type. If you constrain your values to be machine Int, {{{ module M where foo :: Int foo = 1 + 2 }}} Then we see the +# rule fire, {{{ 1 RuleFired 1 +# 4 BetaReduction 3 KnownBranch 9 SimplifierDone ------------------------------- Core ----------------------------------- M.foo :: Int M.foo = I# 3 }}} So perhaps it is a simple matter of adding these rules to the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 31 20:11:22 2008 From: trac at galois.com (GHC) Date: Sat May 31 20:04:14 2008 Subject: [GHC] #2306: The (^) operator sometimes uses one (*) more than needed. In-Reply-To: <044.dff49bec25ebc555eb9d893ae67998f1@localhost> References: <044.dff49bec25ebc555eb9d893ae67998f1@localhost> Message-ID: <053.66720ca9b3ef8b6282ed60f451674f2d@localhost> #2306: The (^) operator sometimes uses one (*) more than needed. ---------------------+------------------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Prelude | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From igloo at earth.li Sat May 31 20:13:06 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat May 31 20:05:53 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080531085450.GA628@scico.botik.ru> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20080528182858.GA16929@scico.botik.ru> <20080529094440.GA415@matrix.chaos.earth.li> <20080529114836.GA18601@scico.botik.ru> <20080529141006.GA12898@matrix.chaos.earth.li> <20080531085450.GA628@scico.botik.ru> Message-ID: <20080601001306.GA11868@matrix.chaos.earth.li> Hi Serge, On Sat, May 31, 2008 at 12:54:50PM +0400, Serge D. Mechveliani wrote: > This is a bug report for the ghc candidate of May 27, 2008 > for ghc-6.8.3. > A short program example for this bug candidate is on > > http://botik.ru/pub/local/Mechveliani/ghcBugs/candidateMay27-08-bug.zip Thanks, I've finally tracked this down. The problem is that when you evaluate something like f ^ 10 in 6.8.2 the result was res while in 6.8.3 it is 1 * res I think this is actually a bug in your class instances, but I will try to look at http://hackage.haskell.org/trac/ghc/ticket/2306 before 6.8.3 which should, as a side-effect, make it work again. Thanks Ian