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 h